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Proced^ et systeme d'etablissement automatique d'un modele global de 

simulation d'une architecture 

Uinvention concerne un procede et un systeme d'etablissement d'un 
5 modele global de simulation d'une architecture. Plus particulierement, 
rinvention concerne un procede de configuration et un systeme dit 
"Configurateur" pour mettre en oeuvre le procede. 

Avec Taccroissement de la complexite des systemes hardware, it faut 
pouvoir trailer, pour la verification de systemes ou circuits integres en projet, 
10 des configurations rassembiant de plus en plus de modeles ecrits en langage 
de description du materiel, par exemple, de type HDL (tels que VHDL ou 
Verilog, les plus utilises) et en langage de haut niveau de type HLL (tels que 
C ou C++), ces langages decrivant, d'une part, les elements constitutifs du 
materiel (hardware) et, d'autre part, les modeles constitutifs de 
15 Tenvironnement de simulation. 

Nous aliens referer comme "Configuration" un ensemble de jjiodeles 
logiciels d'elements dits "Composants" constituant un modele global de 
simulation. 

L'invention est utile dans la verification de la conception des ASICs 
2 0 par simulation de leur fonctionnement. par exemple, dans un environnement 
identique a ou tres proche de leur utilisation finale, le procede de 
configuration permettant le choix de composants et de leurs modeles 
logiciels parmi une pluralite de modeles disponibles pour la constitution de 
configurations de simulation. 

2 5 Dans Tart anterieur les configurations sont rigides et traditionnellement 

preparees "a la main" a I'aide d'editeurs de texte ou d'editeurs graphiques, 
d'apres une liste predefinie de configurations envisageables. Chaque 
modification dans le modele en langage HDL necessite des corrections 
manuelles a repercuter dans I'ensemble des configurations. Cela arrive 

3 0 plusieurs fois au cours du developpement d'un ASIC et constitue une source 

d'erreurs et de difficultes de modification entraTnant des retards de 
realisation. Les modifications de configuration sont souvent sources d'erreurs 
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difficiles a trouver, la taille de certaines configurations pouvant atteindre des 
dizaines de milliers de lignes difficilennent manipulables manuellennent. 

Le temps d'ecriture et de mise au point d'une configuration peut etre 
5 tres long, rendant difficile la generation et Tintroduction de configurations 
nouvelles dans Tenvironnement De ce fait, dans le cas d'un environnement 
contenant beaucoup d'elements pour lequel 11 est difficile de prevoir a 
Tavance toutes les configurations utiles, on renonce souvent a Tutilisation de 
certaines variantes de configurations facilitant le deverminage (configurations 

10 ciblees simplifiees, par exemple). 

Ces difficultes sont accentuees dans les environnements de co- 
simulation, de plus en plus utilises, ou les modeles proviennent de differentes 
sources et sont ecrits en langages de programmation de haut niveau (HLL) 
tels que C, C++, ou en langages de descriptions du materiel (HDL), tels que 

15 VERILOG ou VHDL. Pour le meme composant de la configuration, il existe 
souvent plusieurs modeles (ex : fonctionnel en langage de programmation de 
haut niveau, comportemental en HDL, synthetisable HDL, etc..) qu'on 
aimerait utiliser de maniere transparente selon les besoins. 

De plus, les modeles a connecter presentent souvent, au niveau des 

2 0 interfaces en vis-a-vis, des differences necessitant des modules 
d'adaptation. C'est le cas. par exemple, de circuits avec des interfaces 
d'entree-sortie sophistiques pour lesquels, dans un premier temps, on simule 
le niveau logique du protocole, le niveau physique etant developpe vers la fin 
du projet. Le choix de modules d'adaptation pour des variantes d'interfaces 

2 5 HDL correspondant aux differentes phases de developpement du projet 

constitue un degre de liberte supplementaire qui complique d'avantage 
encore Tecriture des configurations. 

Une autre difficulte vient du fait que les modeles mixtes de type HDL 
(par exemple, VERILOG ou VHDL) / HLL (par exemple, C++) developpes 

3 0 separement, doivent etre mis a jour de maniere coherente. Dans le cas d'une 

gestion non automatisee, c'est une source potentielle d'erreurs. 
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La presente invention vise ^ limiter un ou plusieurs de ces 
inconvenients. 

A cet effet, Tinvention concerne tout d'abord un procede 
d'etablissement automatique, au moyen d'un systeme de traitement de 
donnees associe a un programme dit Configurateur, pour constituer un 
modele global de simulation d'une architecture comprenant des modeles de 
circuits integres en d6veloppement pouvant constituer, a ('aide du 
Configurateur automatique, une machine ou une partie d'une machine et des 
modeles d'environnement de simulation, permettant de tester et de verifier le 
circuit en developpement, d'un fichier de definition de configuration de 
composants de I'architecture, ces composants constituant des blocs 
fonctionnels determines de description des fonctionnalites de circuits integres 
ou de parties de circuits integres, les composants etant choisis par 
I'utilisateur dans une bibliotheque de differents types de composants et une 
bibliotheque de composants d'environnements pour constituer le mode|e 
global de {'architecture repondant ^ la specification fonctionnelle definie dans 
le fichier de definition de configuration et conforme a la specification de 
rarchitecture du modele global specifie par un fichier de description de 
Varchitecture, proced6 caract6rise par le fait qu'il comporte les etapes 
suivantes : 

- lecture du fichier de description d'architecture du modele 
global et memorisation, dans une table de composants et de regies de 
connexion, dans une table de regies de coherence de connexions et dans 
une table de formatage de fichiers source, des informations relatives a 
Tensemble des configurations possibles, chaque composant obtenant un 
nom identifiant, de fagon non equivoque, sa position dans Tarchitecture, ainsi 
qu'un type parmi plusieurs types (Composants actifs, Blocs de Monitoring et 
de Verification, Blocs intermediaires, Blocs systemes et Blocs Globaux), 

- instanciation des composants, specifies dans le fichier de 
definition de configuration par I'utilisateur-concepteur au moyen d'une liste de 
composants presents designes par leurs nom et type et comportant des 
parametres ou faisant appel a des procedures, le fichier de definition de la 
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configuration comprenant un fichier de selection des composants et de leur 
type et des indications suppl6mentaires optionnelles concernant le type 
d'interface et le serveur concerne par la configuration a g^nerer par le 
Configurateur, et memorisation des informations correspondantes dans une 
5 table de connexion des Instances, 

- connexion topologique des instances et memorisation des 
informations correspondantes dans une table de connexion des instances. 

- connexion physique des signaux d'interface, au niveau de 
chaque instance des composants, par application d'expressions 

10 regulieres, memorisees dans la table de composants et de regies de 

connexion, portant sur le nom des signaux constituant une table de 
cablage, 

- utilisation de la table de connexion des instances, de la table 
de cablage et de la table de formatage pour generer automatiquement des 

15 fichiers source de type HDL et de type HLL du modele global de simulation, 
correspondant a la configuration specifiee par le fichier de definition de 
configuration. 

Selon une autre particularite du procede, le systeme Configurateur 
transmet aux parties de type HLL de chaque composant des informations 
2 0 sur : 

- le nom du composant, 

- le type de I'instance, 

le chemin HDL, a savoir le nom hierarchique du composant dans la 
description du modele. 

2 5 Selon une autre particularite du procede, le fichier de definition de 

configuration comporte en plus un mot-cle indiquant le nom ou numero du 
serveur sur lequel se trouve instancie un composant dans le cas d'une 
utilisation du procede sur un systeme multi-serveur. 

Selon une autre particularite du procede, dans le cas d'une utilisation 

3 0 multi-serveur, le systeme Configurateur execute les etapes suivantes : 

- decoupage de la Configuration en plusieurs parties (de type 
HDL et de type HLL) en triant les composants de type HDL 
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et les objets de type HLL selon leurs appartenances aux 
serveurs, 

- generation des composants de type HDL peripheriques^ 
servant a renvoi et la reception des signaux entre les 

5 parties de la configuration, 

- duplication des Blocs Globaux par le syst^me Configurateur 
et instanciation des Blocs Globaux dupliques sur chaque 
serveur, 

- generation des parties de type HLL servant de support de 
10 communication entre les serveurs. 

Selon une autre particuiarite du precede, la connexion automatique 
entre les composants par le systeme Configurateur comprend plusieurs 
phases : 

- une phase topologique de haut niveau realisant la selection 
15 des composants et leurs positionnements respectifs, 

- une phase de cablage realisant la connexion effective entre 
les composants, cette phase generant comme resultat une 
table de c§blage associant les signaux connectes 
ensemble, au nom unique du fil les connectant, 

2 0 - une phase de generation des fichiers sources de type HDL 

et de type HLL. 

Selon une autre particuiarite du procede, la phase de cablage est 
effectuee par le systeme Configurateur selon les trois etapes suivantes : 

a. les Blocs Globaux et les Blocs Systeme sont connectes en premier a 

2 5 tous les composants, 

b. viennent ensuite les connexions des signaux entre les autres 
composants, 

c. a la fin du cablage, une passe supplementaire permet de connecter 
les signaux restant non connect6s de chaque composant a des 

3 0 signaux predetermines pour assurer un etat stable et determine, le 
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systeme Configurateur generant alors . des configurations partielles 

comprenant un sous-ensemble de rarchitecture. 

Selon une autre particularite du procede, les signaux predetermines 
sont les signaux du Bloc Systeme correspondant au composant. 

Selon une autre particularite, le fichler de description de Tarchitecture 
du modele global comprend les modeles de simulation des Blocs globaux et 
des Blocs Systeme, ces deux types de composants etant connectes entre 
eux et gerant des signaux d'environnement. 

Selon une autre particularite, les Blocs Systeme sont connectes aux 
autres composants et leur fournissent des signaux systeme qui leur sont 
sp6cifiques. 

Selon une autre particularite du procede, le systeme de traitement de 
donnees effectue un controle de conformite des connexions en comparant la 
table de connexion des instances reelles entre blocs avec la table de regies 
de coherence de connexions. 

Selon une autre particularite du procedd, le systeme de traitement de 
donnees compare les connexions physiques entre les composants, a la table 
de regies de coherence de connexions, pour detector des incompatibilites 
entre extremites de connexions entre les composants, et, en pareil cas, il 
specifie, et ajoute, dans la table de connexion des instances, un composant 
adaptateur insere dans la connexion consideree. 

Selon une autre particularite, le fichier de definition de configuration 
comprend des informations, specifiees par un attribut, concernant rutilisation 
de composants adaptateurs avec les instances des Composants actifs, dont 
les connexions sont comparees a la table de connexion des instances, pour 
detecter des incompatibilites entre extremites de connexions entre les 
composants, et, en pareil cas, il specifie, et ajoute, dans la table de 
connexion des instances, un autre composant adaptateur insere dans la 
connexion consideree. 

Selon une autre particularite du procede, le systeme de traitement de 
donnees selectionne certaines des connexions entre composants de la table 
de regies de coherence de connexions et specifie, et ajoute, dans la table de 
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connexion des instances, des connexions supplementaires constituent des 
derivations aboutissant a des modeles supplementaires respectifs, 
representant des outils de surveillance des connexions. 

Selon une autre particularite du precede, dans la phase de generation 
des fichiers sources, le systeme Configurateur g6n6re les fichiers source en 
langage HDL et en langage HLL en s'appuyant sur le contenu de la table de 
composants et de regies de connexion, la table de regies de coherence de 
connexions, la table de formatage de fichiers source, la table de connexion 
des instances et la table de cablage. 

Selon une autre particularite du precede, le systeme de traitement de 
donnees effectue un traitement par le systeme Configurateur, pour chaque 
variante de configuration, pour obtenir plusieurs modeles de simulation 
correspondant a la meme specification fonctionnelle, mais ecrits en une 
description comporlant differents melanges des langages de niveaux 
differents (HDL, HLL), 

Selon une autre particularity du precede, le systeme de traitement de 
donnees etablit la specification fonctionnelle du modele global de simulation 
dans un format informatique compatible avec un langage de programnrjation 
de haut niveau (HLL) et en format compatible avec un langage de description 
du materiel (HDL). 

Selon une autre particularite du precede, !e fichier de definition de 
configuration comprend, pour chaque composant, au moins une partie en 
langage de type HDL, ladite partie en langage de type HDL fournissant une 
interface vers d'autres modeles. 

Selon une autre particularite du precede, les modeles comprenant une 
partie en langage de type HLL comprennent des adaptateurs d'interface, 

Selon une autre particularite, le systeme Configurateur choisit chaque 
modele d'adaptateurs d'interface en fonction de la table de regies de 
coherence de connexions. 

Selon une autre particularite du precede, les connexions des signaux 
physiques sent specifies par des "Ports", chaque port etant une selection 
arbitraire des signaux de Tinterface de type HDL d'un composant a I'aide des 
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expressions regulieres portant sur les noms de ces signaux, et etant 
constitu6 de paires expression reguli§re / expression de substitution, ces 
expression etant appliquees successivement au nonn de chaque signal de 
['interface de type HDL, et. si la substitution finale est identique pour deux 
5 signaux, ces derniers sont connectes entre eux, la connexion etant 
memorisee dans la table de cablage. 

Selon une autre particularite du procede, chaque adaptateur 
d'interface etant partage entre plusieurs modeles connectes sur le meme 
port, un seul de ces modeles emet des signaux sur ledit port. 

10 Un autre but de invention est de proposer un systeme Configurateur 

qui permette de pallier un ou plusieurs des inconvenients precedents. 

Ce but est atteint par le systeme de traitement de donnees pour 
I'etablissement automatique d'un modele global de simulation d'une 
configuration de blocs fonctionnels determines, mutuellement relies par des 

15 connexions d'interfonctionnement, pour constituer le modele global de 
simulation d'une architecture comprenant des modeles de circuits integres en 
developpement pouvant constituer une machine repondant a la specification 
fonctionnelle d'une configuration, systeme caracterise par le fait que le 
systeme de traitement de donnees utilise un programme Configurateur qui 

2 0 comprend des moyens de realiser une simulation du cablage par Tapplication 

d'expressions regulieres memorisees, d'utiliser un fichier de definition de 
configuration en langage de haut niveau, une table de composants et de 
regies de connexion decrivant les proprietes (type. Interfaces de type HDL, 
ports, constructeurs d'objets de classes HLL, etc..,) des composants logiciels 
25 de simulation du circuit, une table de regies de coherence de connexions en 
langage de haut niveau (HLL), des moyens d'instancier les elements 
resultants du fichier de definition de configuration, un generateur du code 
HLL qui combine les param^tres des composants avec les regies de 
connexion. 

3 0 Selon une autre particularite du systeme, il existe au moins cinq types 

de composants : les Composants actifs, les Blocs de Monitoring et de 
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Verification, las Blocs intermediaires, les Blocs Systeme et les Blocs 
Globaux. 

Selon una autre particularite du systeme, 11 est agence pour effectuer 
un controle de conformite des connexions en comparant la table de . 
5 connexion des instances avec une table de regies de coherence des 
connexions physiques entre les modeles choisis des blocs constituent le 
modele global. 

Selon une autre particularite du systeme, il est agence pour comparer 
la table de connexion des instances reelles entre blocs a la table de regies 

10 de coherence des connexions, pour detecter des incompatibilites entre 
extremites de connexions entre blocs, et, en pareil cas. pour specifier, et 
ajouter, dans la table de regies de coherence des connexions reelles, un bloc 
fonctionnel adaptateur insert dans la connexion consideree. ^ 

Selon une autre particularite du systeme, la table de composants et de 

15 regies de connexion, comprenant les proprietes des composants, contient 
des parametres globaux communs a tous les types de composants et se 
presente sous forme d'une table repartie suivant une ou plusieurs tables, 
associatives ou non, dont les entrees sont des noms designant Tensqmble 
des modeles possibles pour un m§me composant. 

2 0 Selon une autre particularite du systeme, les tables associatives 

peuvent contenir la description, soit sous forme de suites de parametres, ou 
bien sous forme de references a des procedures qui generent les valeurs 
requises, les entrees de ces tables associatives etant des noms designant 
I'ensemble des modeles possibles pour un meme composant et formant une 

2 5 chaTne de caracteres contenant des identificateurs speciaux predetermines, 

substitues par les valeurs calculees par le systeme Configurateur 

Selon une autre particularite du systeme, au moins trois selecteurs 
indiquent I'instance a prendre en compte, cette derniere etant transmise 
comme parametre a un constructeur d'un objet HLL : 

3 0 - un premier selecteur indique I'instance courante, 

- un deuxieme selecteur precise I'instance connectee a Tautre 
extremite du port, 
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- un troisieme selecteur indique Tinstance composee 
correspondant au Composant actif contenant le port 
d'observation. 

Selon une autre particularite du systdme, le syst^me Configurateur 
5 utilise une ou plusieurs tables de regies de coherence de connexions, qui 
represented les regies d'interconnexion entre les composants et d'insertion 
des composants intermediaires, une ou plusieurs tables de composants et de 
regies de connexions, qui representent les regies de connexion niveau 
systeme et les regies de generation de connexions entre les signaux, et une 
10 ou plusieurs tables de formatage de fichiers source, qui representent les 
regies de generation des instances des objets de type HLL. 

Selon une autre particularite du systeme, le systeme Configurateur 
utilise : 

- une classe de base en HLL permettant d'identifier de fa9on univoque 
15 chaqueobjetinstancieetd'interroger la configuration, 

- des moyens de generation et d'instanciation automatique des Blocs 
Systeme, 

- des moyens des tableaux associant les signaux connectes ensemble 
au nom unique du fils connectant, 

20 - des moyens d'utiliser un tableau de formatage pour generer les 

fichiers sources en HDL et HLL. 

Selon une autre particularite du systeme, Toperateur specifie 
fonctionnellement, dans la plus large mesure possible, la configuration dans 
le langage de plus haut niveau et il complete la specification fonctionnelle par 

2 5 les composants en langage de plus bas niveau. 

Selon une autre particularite du systeme, les entrees suivantes du 
hachage definissent le Type du composant (par exemple DUT (modele HDL), 
XACTOR (transactor). MONITOR, VERIFIER ou autres) et, a chaque Type 
de Composant, correspond un hachage compose a son tour des entrees 

3 0 suivantes: 

- une premiere entree ReqModule - contient le nom du module HDL 
du composant et le nom du fichier source correspondant, 
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- une deuxieme entree Connect - est la definition de la nnethode de 
selection des signaux faisant partie d'un Port, cette description 
etant composee d'une suite d*entrees indexees par le nom du 
Port ; a chaque nom de Port, le configurateur associe un tableau 
5 d'expressions r6gulieres et un pointeur sur une procedure de 

connexion des signaux qui gere Tapplication de ces expressions 
aux noms des signaux de Tinterface du composant 
Salon une autre particularite du systeme, la structure generique des 
Composants actifs comprend un Bloc contenant la description HDL et un 
10 Bloc en HLL, fournissant les chemins d'acces aux ressources HDL et, le cas 
echeant, une description du bloc en HLL, Tensemble des signaux du bloc 
HDL constituent Tinterface du Bloc englobant, formee, d'une part, de Ports, 
qui sont des selections logiques arbitraires des signaux d'une interface et, 
d'autre part, d'adaptateurs dMnterface, qui sont les parties logicielles 
15 assurant, sur chaque Port, la communication bi-directionnelle entre les 
parties en HLL et celles en HDL, les adaptateurs d'interface etant choisia par 
le systeme Configurateur. 

Seion une autre particularite du systeme, les Ports sont specifies sous 
forme d'expressions regulieres, qui servent a ja fois a selectionner les sous- 
2 0 ensembles de signaux a connecter et a definir les regies de connexions. 

Seion une autre particularite du systeme, le systeme Configurateur 
genere des Composants dits de Transfert qui sont inseres de chaque cote de 
la coupure sur les serveurs, ces composants etant simplement des fils pour 
les entrees et des registres pour les sorties. 

2 5 Les composants a modele elementaire qui sont partages entre les 

Composants a Modele Compose ou les Blocs Globaux appartenant aux 
differents serveurs sont automatiquement dupliques par le systeme 
Configurateur et instancies sur chaque serveur. 

3 0 L'invention sera mieux comprise a I'aide de la description suivante 

d'un mode prefere de mise en oeuvre du precede de invention, en reference 
aux dessins annexes, sur lesquels : 
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- la figure 1 represente, sous forme tres schematique, un exemple 
d'architecture du modele global de simulation pour un circuit 
integre (ASIC) en developpement appele BRIDGE (12) ; 

- les figures 2a a 2d sont des diagrammes illustrant les differentes 
composantes du systeme Configurateur et les etapes de mise en 
oeuvre de ces composantes dans le procede de invention ; 

- les figures 3a a 3c representent differents stades de modelisation 
d'un circuit a I'aide d'un modele mixte de type HDL (VERILOG ou 
VHDL) et de type HLL (C++) ; 

- la figure 4 represente la structure generique d*un Modele 
elementaire ; 

- la figure 5 represente la structure generique d'un Modele 
Compose ; 

- ia figure 6 decrit la correspondance entre les tables de la 
description du systeme configurateur sur les figures 2a a 2d et les 
tables de la mise en oeuvre du procede de Tinvention ; 

- les figures 7a a 7k representent schematiquement les differents 
modeles des composants avec leurs variantes d'interfaces et de 
niveau de description necessaires pour les configurations relatives 
a I'architecture de Texemple de la figure 1 ; 

- les figures 8a a 8e representent les configurations successives de 
Tarchitecture aboutissant a une constitution du modele donnee 
dont le modele final correspond a celui de la figure 8e et pour 
lequel tous les modeles de type HDL du circuit en projet sont 
disponibles, ce modele final correspondant a la configuration. 

la figure 8f represente la repartition de la configuration de 
simulation du modele de la figure 8a, par exemple sur deux 
machines. 

L'invention concerne un systdme dit "Configurateur" et le procede de 
configuration mis en oeuvre par le systeme. 
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Un modele global de simulation est typiquement compose d'un ou 
plusieurs modeles de circuits integr6s testes (DUT) entoures de modeles qui 
creent un environnement de test et verification. Ces modeles creent des 
stimuli complexes et regoivent des r6ponses complexes du modele teste. 
Ces composants peuvent etre des transactors (XACTORS) - des modeles 
possedant generalement une Interface programmatique (API) permettant un 
pilotage par des tests externes au modele, ces tests etant ecrits 
generalement en langage de haut niveau (HLL). 

Uenvironnement de verification peut contenir aussi des composants 
dits Bloc de Monitoring (MONITOR) et des composants dits Bloc de 
Verification (VERIFIER). Ces composants ninterviennent pas directement 
dans Techange de signaux entre les autres constituants du modele global de 
simulation mals servent a les observer et a interpreter. Les Blocs de 
Monitoring (MONITOR) servent de support d'analyse pour les tests, ils 
possedent des interfaces programmatiques (API) pour signaler des 
evenements observes sur les signaux de modele global, Les Blocs de 
Verification (VERIFIER) sont des composants qui possedent une 
specification de reference de fonctionnement de modele test6 et, en 
observant les signaux du modele global de simulation, sont capables de 
verifier le bon fonctionnement du modele. 

La figure 1 represente un exemple d 'architecture d'un systeme de 
circuit integre en developpement dont on veut, dans une premiere etape, 
mettre au point le modele global de simulation correspondant a la figure 8c, 
choisie pour illustrer le nombre le plus important de mecanismes mis en 
oeuvre par le configurateur. II doit etre clair que les etapes des figures 8a, 8b 
pourraient etre d'abord executees selon la disponibilite des modeles et les 
objectifs de verification. Le modele final souhaite est celui correspondant a la 
figure 8e. L'architecture est constituee d'un processeur (CPU) communicant 
par une passerelle (BRIDGE) avec une memoire systeme (MEMORY) et des 
entrees sorties (I/O). Le modele auquel aboutit le systeme "Configurateur" de 
rinvenfion est constitue d'un composant processeur CPU de type XACTOR 
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relie par une interface de type "fbus_p" a un bloc intermediaire (fbus_xchg) 
101 ayant une Interface de type different. Un autre bloc intermediaire 
(fbus__xchg) 102 figures 8b et 8c relie le premier bloc intermediaire 101 a un 
composant de type passerelle (BRIDGE) de type DUT_CORE qui 
communique, d'une part avec un modele majoritairement en langage de type 
HDL d'une memoire (MEMORY) de type DUT, d'autre part avec un modele 
majoritairement en langage de type HDL d'une entree/sortie (I/O) de type 
DUT et enfin avec un bloc systeme (SYS_BRIDGE). 

Le systeme "Configurateur" de {'invention gere la connexion 
d'elements logiciels de simulation appeles composants pour les besoins de 
la simulation des circuits hardware. 

II existe au moins 5 classes de composants : 

- Les "Composants actifs" (voir ci-apres) ; 

- Les "Blocs de Monitoring et de Verification" (voir ci-apres) ; 

- Les "Blocs intermediaires" (voir ci-apres) ; 

- Les "Blocs Systeme" (voir ci-apres) ; 

- Les "Blocs Globaux" (voir ci-apres et 1 de A2), 

Chaque type de composant peut posseder plusieurs variantes de 
realisation d'un meme element, differenciees par le niveau de description 
(voir ci-apres) ou par les signaux sur les interfaces (voir ci-apres). Chaque 
type de Composant peut etre decrit a plusieurs niveaux de details 
(fonctionnel, comportemental, portes, etc.) en langage de type HDL, tel que 
VERILOG ou VHDL. ou en langage de haut niveau (HLL), tel que C ou C++ 
complete d'une interface de type HDL. 

Plusieurs niveaux de descriptions peuvent coexister pour decrire des 
fonctionnalites similaires et avoir des interfaces de type HDL similaires mais 
pas forcement identiques. Certaines descriptions peuvent avoir plus de 
fonctionnalites, et les interfaces de type HDL peuvent contenir des jeux de 
signaux completement differents. 
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Les composants sont connectes selon un schema predetermine 
considere fixe pour chaque execution du syst6me Configurateur. Ces 
connexions sont definies par I'architecture du modele global de simulation et 
specifiees par le fichier de description d'architecture . (FDARCH) (voir 
5 annexes A1-A5). 

Chaque instance d'un composant dans ce schema obtient un nom ou 
label qui identifie de fagon non equivoque la position du composant et son 
type. 

Le fichier de definition de la configuration (FCONF) fournit une 
10 description synthetique de la variante de Configuration a generer par le 
systeme Configurateur. Seuls les composants principaux (Composants 
Actifs. Blocs de Monitoring et Blocs de Verification) y sont mentionnes avec 
les types de modeles souhaltes. Les autres composants (Blocs Globaux, 
Blocs Systeme et Blocs Intermediaires) seront instancies automatiquement 
15 par le systeme configurateur. 

Parmi les differents types de composants, les "Composants Actifs" 
constituent le sous-ensemble des objets explicitement designes dans le 
fichier de configuration (FCONF) et qui echangent des stimuli en emission.et 
reception avec leur environnement. 
2 0 Parmi les differents types de composants, les "Blocs de Monitoring et 

Verification" constituent ie sous-ensemble des objets, explicitement designes 
dans le fichier de configuration (FCONF), qui ne font que recevoir des 
informations de leur environnement. lis sont utilises a des fins d'observation 
et de Verification (MONITOR, VERIFIER). La granularite de traitement de 

2 5 ces modeles est Tev^nement qui rend compte des changements de valeurs 

des signaux de controle et des echanges arbitraires de donnees. 

Tous les autres Composants constituent des composants dits 
implicites, qui sont geres et instancies de fagon automatique par le systeme 
configurateur. en fonction des parametres du fichier de configuration 

3 0 (FCONF) (type de composants explicites, type d'interface, ...). 

Les composants peuvent etre connectes entre eux directement ou par 
i'intermediaire de composants d'adaptation externe dits "Blocs 
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Intermediaires" definis et declares specialement a cet effet. lis sont souvent 
utilises, comme nous le verrons par la suite, lors des phases successives de 
developpement pour completer les parties manquantes du design. 

Le systeme Configurateur peut inserer ainsi un ou plusieurs blocs 
5 intermediaires pour connecter deux composants actifs. 

Les composants dits "Blocs Systemes" sont associes aux autres 
composants pour leur fournir les signaux d'environnement qui leur sont 
specifiques. Ces composants encapsulent, au niveau de chaque interface, 
Tensemble des signaux systeme ne participant pas a la connexion entre les 

10 autres composants. Les "Blocs Systemes" sont eux-memes connectes aux 
"Blocs Globaux" et gerent Tensemble des signaux d'environnement : les 
signaux - d'horloge et de controle general (clock, reset, powergood, 
diagnostic), qui peuvent etre eventuellement transformes pour les adapter au 
besoins du bloc actif correspondant (changement de polarite, retard etc.), 

15 ainsi que les signaux specifiques, differents pour chaque instance partlculiere 
du composant actif concerne, par exemple les signaux codant le numero de 
module ou le mode de fonctionnement du composant, etc. Ces derniers 
sont geres par des parametres fournis par le systeme Configurateur aux 
instances de modeles des composants generes. Si, pour un Composant 

2 0 donne, le Bloc Systeme n'est pas necessaire (ce qui est indique par les 
tables de description de la configuration), il sera relie directement aux Blocs 
Globaux (cf. 1 de A2). 

Le fichier de configuration (FCONF) peut contenir des informations 
supplementaires specifiant des blocs intermediaires a utiliser en association 

2 5 avec les instances des composants actifs. Ainsi, I'utilisateur peut influencer le 

choix du composant intermediaire, ou lever TambiguTte, dans le cas de 
plusieurs choix possibles. Les connexions ainsi obtenues sont comparees a 
la table de regies de coherence de connexions (TRCOH) pour detecter des 
incompatibilites entre extremites de connexions entre les composants et, en 

3 0 pareil cas, choisir et ajouter, dans la table de connexion des instances 

(TCINST), encore un composant adaptateur (Bloc Intermediaire) insere dans 
la connexion consideree. 
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Le systeme Configurateur s'appuie sur une representation generique, 
telle que decrite sur les figures 3a ^ 3c, connmune a Tensemble des 
composants declares dans le fichier de description d'architecture (FDARCH) 
5 du modele global de simulation, et comprenant deux parties, de type HDL 
(par exemple VERILOG ou VHDL) et de type HLL (par exemple C++). 

Dans le cas d'un composant decrit completement en langage de type 
HDL (figure 3a), la partie de type HLL est reduite ^ une Instance qui permet 
de signaler sa presence dans la Configuration au cours de la simulation et 
10 qui fournit les chemins d'acces aux ressources de type HDL du composant. 

Pour les composants decrits en langage de type HLL (figure 3c), c'est > 
la partie de type HDL qui est reduite au strict minimum, et qui est limitee a la-. -r , 
description des signaux et registres d'interface. ^ 

Tous les niveaux intermediaires entre ces deux extr^mites sent - ;^ 

15 possibles et naturellement exploites dans le contexte de processus de 

developpement des circuits ASIC. , - 

Typiquement, au cours d'un developpement, on commence par un 
modele de type HLL avec une interface de type HDL minimaie et, en.suite, on ; 
passe ^ des modeles de type HDL de plus en plus complets Merits par les r , 
2 0 concepteurs et on termine par les modeles du niveau portes logiques 
synthetises automatiquement a partir de modeles de type HDL. 

Les modeles mixtes sont souvent utilises parce qu'ils permettent une 
simulation precise et efficace en dediant le langage de haut niveau (HLL) aux 
modelisations complexes pour lesquelles le langage de type HLL offre une 

2 5 description compacte et rapide a Texecution. Neanmoins, meme pour les 

modeles ecrits majoritairement en langage de type HLL, la partie de type 
HDL peut etre non triviale pour des raisons de pertes de performances dues 
aux changements de contexte de simulation entre, respectivement, les 
parties de type HDL et de type HLL. Un exemple typique est une interface 

3 0 dont les signaux changent, meme sans activite reelle de transfert de 

donnees. Dans ce cas, il est preferable de traiter les signaux dans la partie 
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de type HDL du modele. et de passer ^ la partie de type HLL quand les 
donnees sont presentes sur Tinterface. 

Uinterface d'un composant est I'ensemble de tous les signaux 
presents a sa peripherie. Pour les composants decrits uniquement en 
5 langage de type HDL, cela correspond a interface externe de la definition de 
ce composant en langage de type HDL (par ex. VERILOG ou VHDL). Pour 
les composants definis de maniere mixte en langage de types HLL et HDL, 
interface d'un composant est la somme des signaux de tous les modules de 
type HDL utilises a la peripherie de ce composant. 
10 La figure 4 decrit la structure generique des modeles elementaires 

constituant la majorite des composants. Cette structure s'applique 
typiquement, mals pas uniquement, au cas du circuit ASIC en 
developpement. des adaptateurs d'interface, blocs intermediaires, blocs 
systeme. 

15 Elle comprend un Bloc englobant note C contenant la description de 

type HDL notee A et le Bloc HLL note B fournissant les chemins d'acces aux 
ressources de type HDL et, le cas echeant, une description du bloc en 
langage de type HLL. L*ensemble des signaux du bloc de type HDL constitue 
rinterface du bloc C, Pour les besoins de connexion entre les blocs nous 

2 0 utilisons la notion de Ports (voir plus loin) qui sont des selections logiques 
arbitraires des signaux d'une Interface. II est possible qu'un signal 
appartienne a plusieurs Ports a la fois. 

Le systeme Configurateur est capable de traitor des modeles dits 
'composes' comprenant une partie en langage de type HLL et incluant 

2 5 d'autres modeles des composants dits 'adaptateurs d'interface*. Les 

adaptateurs d'interface sont des modeles mixtes de types HDL / HLL 
possedant une interface programmatique (API) en langage de type HLL par 
laquelle lis peuvent communiquer avec le modele compose. Les modeles 
composes sont particulierement utiles pour les composants d'environnement 

3 0 de simulation (par exemple MONITOR, VERIFIER, XACTORS) ou le modele 

doit s'adapter a des signaux presents sur les differentes variantes des 
modeles utilises dans une configuration. 



1 er depot 



19 



La figure 5 decrit la structure generique de modeles composes, utilises 
surtout pour modeliser les constituants de I'environnement de simulation. Vu 
de sa presentation exterieure, le modele compose est identique au modele 
el6mentaire. A rinterieur, la specification HLL du modele (notee D) 
5 communique avec Tinterface exterieure de type HDL a travers les 
adaptateurs d'interface (notes C_Port)i modelis6s au moyen de structures 
el6mentaires en langage de type HLL (notees B_PORT) et en langage de 
type HDL, (notees A_PORT). 

Le systeme Configurateur est agence pour selectionner 

10 automatiquement les adaptateurs d'interface pour un modele compose. Le 
systeme Configurateur examine la liste d'adaptateurs d'interface utilisables 
pour un modele compose donne decrit par les proprietes du modele. et 
choisit le modele d'adaptateur d'interface dont les connexions physiques 
avec le reste du modele global sont en conformite avec la table des regies de 

15 coherence de connexions (TRCOH). Cette approche permet une rapide 
adaptation a de nouveaux types d'Interfaces en ajoutant de nouveaux 
adaptateurs. 

II est important de souligner qu'un m§me composant peut aussi fc>ien 
etre modelise par une structure elementaire, ou composee, suivant son 

2 0 niveau de description. 

Un composant adaptateur d'interface peut etre partage entre plusieurs 
modeles composes connectes sur le meme port. Un seul d'entre ces 
modeles est autorise a emettre des signaux sur le port, les autres modeles 
etant purement observateurs. Une utilisation typique concerne les blocs de 
25 Monitoring et Verification qui n'envoient pas de signaux en sortie. Le partage 
des adaptateurs d'interface accelere la simulation par la simplification et la 
factorisation des parties du modele. 

On appellera par la suite Sondes, les adaptateurs d'interface servant a 
observer les signaux pour le compte des Blocs de Monitoring ou de 

3 0 Verification qui sont des Modeles Composes. 

Le systeme Configurateur est congu pour optimiser Tutilisation des 
Sondes en minimisant leur nombre. Comme la description des Composants 
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etablit la notion d'6quivalence entre certains Composants, le systdme 
Configurateur essaye d'abord de partager le port d'un "Composant actif '. Si 
cela s'avere impossible, il instancie un composant Sonde ad6quat 
connectable sur {'interface de type HDL a partir d'une liste fournie dans la 
description du Composant Monitoring ou Verification. 

La partie ci-apres d6crit les definitions relatives aux connexions entre 
Composants. Les notions d'interface et de port servent de support a la 
description des connexions entre les composants. 

Nous rappelons que le port est une selection arbitraire des signaux de 
I'interface de type HDL d'un composant, realisee a I'aide des expressions 
regulieres portant sur les noms de ces signaux. Un signal donne peut 
appartenir a un ou plusieurs ports. La definition de chaque port est constituee 
de paires de type expression reguliere et expression de substitution 
correspondante. Ces expressions sont appliqu6es successivement au nom 
de ciiaque signal de I'interface et, en cas d'ad§quatiqn 'match', {'expression 
de substitution est appliqu6e et le nom ainsi obtenu passe au traitement de la 
substitution suivante. Si la substitution finale donne un resultat fina{ identique 
pour deux signaux, ces demiers seront connectes ensemble. Le 
configurateur genere un nom unique pour la connexion et place les 
informations ad6quates dans la table de cablage (TCAB). La methode d6crite 
permet d'exprimer des regies complexes de connexion entre deux 
composants. Par exemple on peut connecter des signaux de noms differents, 
ou creer des regies de connexion des signaux d'entree avec les signaux de 
sortie. 

La creation de cette metiiode de definition par les interfaces et les 
ports permet un decouplage entre les declarations de modules de type HDL 
et les specifications de connexions pour le systeme Configurateur. Ce 
dernier combine ces deux sources d'information pour generer les 
connexions. Dans la majorite des cas, les modifications de declarations dans 
les parties de type HDL, tres frequentes pendant le developpement, 
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n'entratnent pas de modifications dans les expressions regulieres decrivant 
les c§blages. 

Dans Texemple de mise en cBuvre de I'invention traite ci-apres, seules 
les connexions point a point sont traitees. Les connexions de type "bus" sont 
facilement modelisables en utilisant un composant a plusieurs sorties 
englobant le bus. 

Nous allons decrire ci-apres le precede de connexion automatique 
entre les "composants" par le systeme Configurateur pour constituer le 
modele global de simulation. Ce procede comprend les etapes suivantes : 

- Lecture du fichier de description d'architecture (FDARCH) du 
modele global et memorisation, dans une table de composants et 
de regies de connexion, dans une table de regies de coherence de 
connexions et dans une table de formatage de fichiers source, des 
informations relatives a I'ensenible des configurations possibles, 
chaque composant obtenant un nom identifiant, de fagon non 
equivoque, sa ppsition dans Tarchitecture, ainsi qu'un type parmi 
plusieurs types (Composants actifs, Blocs de Monitoring et de 
Verification, Blocs interm6diaires. Blocs systemes et Blocs 
Globaux). 

- Instanciation des composants, specifies dans le fichier de definition 
de configuration par rutilisateur-concepteur au moyen d'une liste 
de composants presents designes par leurs nom et type et 
comportant des parametres ou faisant appel a des procedures, le 
fichier de definition de la configuration comprenant uri fichier de 
selection des composants et de leur type et des indications 
supplementaires optionnelles concernant le type d'interface et le 
serveur concerne par la configuration a generer par le 
Configurateur, et memorisation des informations correspondantes 
dans une table de connexion des instances. 

- Connexion topologique des instances selon le schema defini par la 
table de composants et de regies de connexions (TCRC). 
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Lecture et memorisation des sources de type HDL des modeles 
instancies pour en extraire les noms et types des signaux 
d'interfaces. 

Cablage des signaux d'interface au niveau de chaque instance des 
composants par application d'expressions regulieres, stock^es 
dans la table de composants et de regies de connexions (TCRC). 
et portant sur le nom des signaux constituant la table de cablage 
(TCAB). 

Utilisation de la table de connexion des instances (TCINST), de la 
table de cablage (TCAB) et de la table de formatage (TFMT) pour 
generer automatiquement les fichiers source de type HDL 
(MGHDL) et de type HLL (MGHLL) du modele global de simulation 
correspondant a la configuration specifiee par le fichier de 
configuration (FCONF). 

Le deroulement de la phase topologique est le suivant : 
Les Composants explicites specifies dans le fichier de 
configuration (FCONF) sont instancies en premier par le systeme 
Configurateur et places dans la table de connexion des instances 
(TCINST). Cette table contient le descriptif de chaque instance 
(label, type), accompagne de la liste des composants avec 
lesquels il est connecte. 

Ensuite, les Blocs Intermediaires, specifies explicitement sur les 
ports des "Composants actifs" dans le fichier de configuration, sont 
instancies et ajoutes dans la table de connexion des instances 
(TCINST). 

Les connexions entre les composants actifs instancies sont 
comparees avec les regies contenues dans la table de coherence 
de connexions (TRCOH) pour detecter des incompatibilit^s entre 
les extremites des connexions entre les composants et, dans ce 
dernier cas, pour choisir et ajouter, dans la table de connexion des 
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instances (TCINST), un composant adaptateur (Bloc Intermediaire) 
a insurer dans la connexion consideree. 

- Ensuite sont instancies les composants de type Bloc de Monitoring 
et Bloc de Verification. Le systeme Configurateur analyse les 

5 connexions des composants a modele compose et cherche des 

adaptateurs d'interface partageables au niveau des ports commun 
(voir modeles C__Porlj sur la Figure 3). S'il n'existe pas de 
composant approprie pour partager la connexion en observation 
des signaux requis, un composant adaptateur d'interface aux 
10 proprietes specifiees par la description sera instancie par le 

configurateur. La table de connexion des instances (TCINST) est 
remise a jour. 

- Enfin, les composants 'bloc systeme' sont instancies et places 
dans la table de connexion des instances (TCINST), pour les 

15 composants qui en ont besoin. 

En phase de Cablage, le systeme Configurateur connecte les signaux 
d'interface au niveau de chaque port par application d'expressions regulieres 
portant sur les noms des signaux comme decrit dans la definition du port. 
2 0 Ces expressions sont appliquees aux noms des signaux extraits a partir des 
descriptions de type HDL des composants, de telle sorte que les 
changements des interfaces de type HDL d'une version de modele a Tautre 
n'influent pas directement sur les specifications des connexions entre les 
blocs. Cette phase genere comme resultat la table de cablage (TCAB) 

2 5 associant les signaux connectes ensemble, au nom unique du fil les 

connectant. Un certain nombre de verifications sont alors possibles, portant 
par exemple sur les connexions sans source, ou la connexion de plusieurs 
sorties ou autres. 

3 0 Les differentes etapes de la phase de cablage sont les suivantes : 
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- Les Composants Globaux et Blocs Systehne sont cables en 
premier a tous les composants. 

- Ensuite sont cables les signaux entre les autres composants. 

- A la fin du cablage, une passe supplementaire permet de 
5 connecter les signaux d'un composant non connectes dans les 

phases precedentes de cablage a des signaux du bloc systeme 
correspondents, specialement prevus pour forcer des valeurs 
connues et stables inhibant les ports non utilises. Les signaux 
concernes des blocs systeme portent un marquage special (par 
10 exemple un prefixe special dans le nom) pour ne pas etre 

connectes au cours des phases de cablage precedentes. 

En phase de generation des sources, le systeme Configurateur 
genere les fichiers source de type HDL et de type HLL en s'appuyant sur le 
15 contenu de la table de connexion des instances (TCINST), de la table de 
cablage (TCAB) et de la table de formatage (TFMT) pour generer 
automatiquement les fichiers source de type HDL (MGHDL) et de type HLL 
(MGHLL) du modele global de simulation correspondent a la configuration 
specifiee par le fichier de configuration (FCONF). 

2 0 Le fichier source de type HDL contient une description de la partie de 

type HDL (par exemple en VERILOG) du modele global de simulation 
correspondent au fichier de configuration (FCONF). En particulier, il contient 
rinstanciation de tous les modeles de type HDL des composants explicites 
dans le fichier de configuration, les blocs intermediaires, Blocs Systeme et 

2 5 les Bloc Globaux ainsi que tous les fils reliant ces instances. 

Le fichier source de type HLL contient le programme correspondant a 
rinstanciation de tous les composants possedant une partie de leur modele 
en langage de type HLL. Dans le cas de langages HLL orientes objet, le 
code contient les constructeurs d'objets de classes HLL avec les parametres 

3 0 correspondents specifies dens la description de cheque composant. Un 
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tableau de formatage (TFMT) specifique a chaque projet permet la 
generation du code de type HLL approprie. 

Nous allons decrire le fichier de description d'architecture 
(FDARCH) pour une implementation specifique du systeme configurateur 
5 (PROGCONF) en langage PERL, choisi a cause de la manipulation directe 
des expressions regulieres et des tables associatives a plusieurs niveaux. 

Uarchitecture, representee sur la figure 1, est constituee d'un 
processeur (CPU) communicant par une passerelle (BRIDGE) avec une 
memoire systeme (MEMORY) et des entrees sorties (I/O). 

10 Le fichier FDARCH represents a e^te decoupe pour faciliter son 

ecriture et sa manipulation en plusieurs parties presentees dans les annexes 
A1 a A5. Ce fichier definit Tarchitecture du modele global de simulation 
correspondant au schema g6nerique represents sur la figure 1. Le langage 
de type HDL genere est VERILOG et le langage de haut niveau (HLL) 

15 genere est le C++. 

Les proprietes des Composants (type, Interfaces de type HDL, ports, 
constructeurs d'objets de la classe C++, etc..) sont decrites dans plusieurs 
tables ecrites en langage PERL. La correspondance entre ces tables -et le 
diagramme illustrant le systeme Configurateur de la figure 2 est representee 

2 0 sur la figure 6. Dans la suite de la description, toutes les notations 
commengant par "%..." correspondent a des tables de hachage. 

Ces tables peuvent contenir la description, soit sous forme de suites 
de parametres, soit sous forme de references d des proc6dures qui gSnerent 
les valeurs requises. 

2 5 Les procedures font partie de la description et sont changees pour 

chaque projet L'exemple typlque de leur utilisation est la generation 
d'interconnexion entre les composants. Souvent, le tableau correspondant a 
toutes les interconnexions possibles serait trop grand et difficile a generer et 
maintenir. En revanche une procedure peut etre tres compacte. 

3 0 La description des regies d'interconnexion des composants (TCRC) 

contient des parametres globaux communs a tous les types de composants. 
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Elle peut se presenter sous forme d'au moins une table. Dans le mode de 
realisation de la figure 6, elle se pr6sente sous forme de sept tables 
associatives (hachages), dont trois ont pour entrees (%lnstNameModuleMap, 
%SysConnectMap, %SysSpecMap) les noms designant Tensemble des 
5 modeles possibles pour un meme composant : 

- La table "%lnstNameModuleMap" (cf. 2 de A1), qui figure dans le 
fichier patent_config_defs.pm, pour decrire les Composants explicites. 
Cette table represente les regies de generation de connexion entre les 
signaux. Elle a pour entries Connect et SelfConnect. 

10 - La table "%SysConnectMap" qui figure dans le fichier 
patent_Sysconfig_defs.pm pour les Blocs Systeme. 

- La table "%SysSpeGMap" (cf. 4 de A2) qui figure dans le fichier 
patent_Sysconfig_defs.pm pour les Blocs Intermediaires. 

Les deux tables de hachage %SysWrapMap et %SysPinConst (cf. 6 de A2) 
15 contiennent les regies de connexion niveau systeme. La table de hachage 
%Activity_TypeMap associe le nom d'un composant avec son type. La table 
de hachage %PortProbeMap a pour entrees les noms des modules de type 
HDL utilisee dans la description des composants. 

Le systeme Configurateur est pilots par au moins une table de regies 
2 0 de coherence de connexions (TRCOH) qui represente les regies 
d'interconnexlon entre les composants et d'insertion des composants 
intermediaires. Dans le mode de realisation de la figure 6, les regies de 
coherence de connexions sont reparties sous forme des deux tables 
suivantes : 

2 5 . %HwfConnectivityMap (cf. 2 de A2) 

%HwifAitemateMap 
Le systeme Configurateur est pilote par au moins une table de 
formatage de fichiers source (TFMT) qui represente les regies de generation 
des instances des objets de type HLL. Dans le mode de realisation de la 

3 0 figure 6, les regies de generation des instances des objets de type HLL sont 

reparties sous forme des deux tables suivantes : 



1 er depot 



27 



. %moduleToCppClassMap (cf. 1 de A5) 
. %classCppProtoMap (cf. 2 de A5) 
Le role de chacune de ces tables de hachage est detaille ci-apres. n 

Parmi les entries definies pour les tables %lnstNameModuleMap, 
%SysConnectMap. %SysSpecMap, certaines sont obligatoires : 

- L'entree "Match Expr", dont la valeur est rexpression reguliere qui 
permet d'accepter un nom (label) du composant dans le fichier de 
configuration, est utilisee pour definir les variantes de positions 
autorisees pour le composant. 

- Uentree "ExtrExpr", dont la valeur est I'expression reguliere qui assure 
Textraction des parametres numeriques a partir du nom (label), est 
utilisee pour rinstanclatidn des Blocs Intermediaires ou des Blocs 
Systeme ou pour generer le label du composant implicite. 

D'autres parametres sont facultatifs et peuvent etre ajoutes a la 
description des tables mais ces parametres ne peuvent etre utilises que par 
le code fourni avec la description - parmi eux : 

- NumAdd est un parametre auxiliaire servant de modificateur pour les 
parametres extraits par ExtrExpr, exploite par la procedure GenDest 
(voir ci-apres). 

- Baseld Expr est une expression reguliere qui permet de retrouver le 
composant actif correspondent a un composant intermediaire ou 
systeme en cas d'ambiguTte. 

Les entrees suivantes du hachage definissent le Type du composant 
tel que, par exemple, DUT (module de type HDL), XACTOR (transactor), ou 
autres. 

A chaque Type de Composant, correspond un hachage compose a 
son tour des entrees suivantes : 

- L'entree "ReqModule" - contient le nom du module de type HDL 
(VERILOG) du composant et le nom du fichier source correspondant. 
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- L'entree "Connect" - est la definition de la mdthode de selection des 
signaux faisant partie d'un Port. Cette description est composee d'une 
suite d'entres indexes par le nom du Port. A chaque nom de Port on 
associe un tableau d'expresslons reguii^res et un pointeur sur une 

5 procedure de connexion des signaux qui gere ('application de ces 

expressions aux noms des signaux de I'interface du composant. 
Le Configurateur dispose de plusieurs procedures preprogrannnnees mais 
d'autres peuvent etre ajoutees et referencees. Les procedures 
preprogrammees acceptent des modificateurs : 
10 -> E (exdusif - le signal ne sera utilise qu'une seule fois) 

^ T(derivation - le signal peut etre utilise par plusieurs destinations). 
Une valeur speciale 'filter__out_wire_name', attribue a un signal ou 
un groupe de signaux permet d'eliminer toute connexion sur les 
signaux correspondants. 

15 - L'entree "SelfConnect" - similaire a I'entree "Connect" contient les 
definitions des connexions des signaux de Ports qui peuvent etre 
. connectes entre deux instances d'un meme composant - cette definition 
facilite la connexion de signaux unidirectionnels sortie -> entree dans le 
cas particulier de connexion tete-beche. 

20 - L'entree "Port" - fournit la definition de i'ensennble des ports, C'est un 
hachage qui associe le nom de chaque port ^ un tableau comportant les 
elements suivants : 

• Le nom logique du composant de type HDL. 

• Le nom du module de type HDL ou un choix de modules. 

2 5 • Le numero du port (utile pour la generations du code VERILOG et 

C++). 

- L'entree "GenDest" (cf. i de A3) - est un pointeur sur la procedure 
qui, pour un composant designe par un label et type, gen^re, pour 
chaque port, le label du composant auquel 11 se connecte. La 

3 0 procedure referencee dolt etre imperativement specifiee par 
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Tutilisateur - cette procedure est egalement utilisee pour controler ia 
coherence de la configuration dennandee 

L'entree "SysConn" - est un hachage qui associe a chaque module de 
type HDL contenu dans le modele un pointeur sur la procedure de 
selection et nommage des Blocs Systeme. La procedure referencee 
doit etre imp^rativement sp6cifiee par rutilisateur. 
Uentree "GenHDLInstParam" - est un pointeur sur la procedure qui 
g^nere les parametres supplementaires requis par le simulateur de 
type HDL pour le code gen6re qui instancie la partie de type HDL du 
composant. 

L'entree "CfgCpp" - definit les parannetres du constructeur de Tobjet 
pour le code C++ d'identification de la Configuration, genere 
automatiquement, servant de filtrage pour la selection des 
Composants par le systeme Configurateur : 

. Le premier parametre est le nom de la classe de Tobjet C++ - c'est 
un nom predefini associe a celui du modele de type HDL ~ il est 
suivi par les tableaux correspondents a des groupes ; de 
parametres associ6s typiquement a chaque port du composanfe Le 
mot-cle "Own" indique un composant a modele elementaire. 

. Ensuite viennent le nom du composant de type HDL reference 
dans la partie Port et I'identifiant de type du composant tels, par 
exemple, DUT, modele du circuit en projet; XACTOR. transacteur 

. Pour les blocs a modele compose, la partie parametres est plus 
riche : 

Elle contient le mot cle "Src" pour les composants actifs ou 
"Mon " pour les composants de Verification et Monitoring 
-> Viennent ensuite les parametres du composant adaptateur 
d'interface, comprenant : 

le nom du composant de type HDL. 

Tidentifiant du type du composant et sa classe suivie du 
nom du port correspondant. 
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Ces derniers parametres sont specifies pour chaque port du 
bloc compose. 

Dans le code C++ gen6r6 pour un modele compose, les parametres 
transmis au constructeur d'une classe correspondent aux pointeurs sur les 
instances des adaptateurs d'interface, 

Tous ces parametres servent a guider le generateur du code C++ qui 
les combine avec les regies contenues dans le tableau de hachage 
"%classCppProtoMap" 

- Uentree "ProbeConnect" — associe d chaque port d'un composant 
Moniteur ou Verifieur la classe C++ acceptable comme adaptateur 
d'interface. Ainsi le Configurateur est capable d'optimiser le code en 
utilisant le meme adaptateur d'interface pour plusieurs composants 
(modele compost). 

- Uentree "SysWrap" - est un hachage qui pour chaque partie de type 
HDL d'un composant definit {'expression reguliere a utiliser pour 
mettre a un etat connu les signaux restes non connect6s apres le 
cablage entre les composants. 

L'algorithme de connexion de deux composants est le suivant : 

- Le systeme Configurateur essaye d'abord la connexion directe. 

-Si celle-ci s'avere impossible d'apr^s la premiere table de hachage 
%HwfConnectivityMap, les modules specifies dans 
%HwifAlternateMap sont pris en compte pour etre places dans le 
composant. Les modules a choix sont indiques par le caractere 
au debut de leur nom dans la specification d'un composant 

-A la fin. si aucun module ne convient, le systeme Configurateur revient 
au hachage %HwfConnectivityMap pour choisir les blocs 
intermediaires a placer entre les composants. 

- Si aucun bloc adequat n'est trouve une erreur est signalee. 
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L'utilisateur peut influencer les choix du systeme Configurateur en 
specifiant explicitement dans le fichier de configuration les blocs 
intenT»6diaires a connecter ^ un composant. 

Le tableau "%HwfConnectivityMap" permet a la fois la Verification de 
connectivite et la specification de Blocs jnterm6diaires a inserer pour 
connecter deux Composants dont les ports ne sont pas directement 
connectables. 

Pour que deux blocs puissent etre connectes entre eux, il faut que 
%HwfConnectivityMap contienne des entrees qui decrivent les proprietes de 
cette connexion : 

-A chaque composant, on associe le composant auquel 11 peut etre 
connecte. 

- Une connexion directe est ihdiquee par la valeur "Direct". 

- Pour les connexions necessitant un Bloc intermediaire, le nom de ce 

bloc est indique. 

- Pour certains blocs, la connectivite peut etre specifiee differemment 

pour chaque port du bloc. Cela sert a lever I'ambigmte sur les 
connexions d'un bloc. Une utilisation typique concerne I'insertion de 

.if 

deux blocs intermediaires connectes tete-beche entre deux 
composants explicites. 

On souligne que la connectivite est exprimee ici de maniere globale, 
sans specifier les noms de signaux a connecter. 

Les Composants decrits en langage de type HLL peuvent posseder 
plusieurs implementations possibles des modules de type HDL A^Portj au 
niveau de chaque port i (voir Figure 3). La table de hachage 
"%HwifAlternateMap" specifie le choix possible pour chaque module de type 
HDL d'un composant. Le systeme configurateur utilise cette information pour 
ne placer les blocs intermediaires qu'en cas de stricte necessite. 

Le hachage 7oSysWrapMap definit, pour chaque implementation d'un 
composant, son Bloc Systeme. Les entrees sont des noms de modules de 
type HDL associes avec le nom du bloc systeme et son implementation de 
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type HDL. Ces informations sont utilisees par le systeme Configurateur pour 
instancier le bloc systeme ad6quat a partir de specifications contenues dans 
le hachage %SysConnectMap (cf. 3 de A2). 

Le hachage %SysPinConst associe a chaque Bloc Systeme, les 
5 connexions de certains signaux de son interface aux noms des signaux 
(wires) correspondants au niveau systeme. Ces connexions sont 
independantes des configurations et ne sont pas regies par les expressions 
regulieres applicables lors du cablage des autres signaux. 

Typiquement, les signaux concernes sont des signaux d'horloge, de 
10 remise a zero (reset), etc... Les noms references sont declares dans un code 
de type HDL, specifique pour chaque modele en projet (design), et fournis 
par Tutilisateur (sous forme d'une variable ou d*un fichier) avec les 
descriptions des composants et des regies de connexion specifiques, 

Ce code specifique de type HDL est inclus systematiquement au 
15 debut du code de type HDL gener6 par le systeme Configurateur. 

La procedure "&gen_sys_VloglnstParameter" est une procedure qui 
genere les parametres d'instantiation pour le generateur du code de type 
HDL a partir du label et du type de chaque Composant. 

Le hachage %Activity_TypeMap (cf. 1 de A1) associe le nom d'un 

2 0 composant avec son type specifie par un mot cle: 

'actor' pour les composants actifs. 
'spectator' pour les blocs de Monitoring, 
'checker' pour les blocs de Verification. 

'helper' pour les blocs Systeme ou les blocs Intermediaire en cas 
25 de connexion indirecte. 

. La table "%PortProbeMap" est un hachage dont les entrees sont les 
noms des modules de type HDL utilises dans la description des composants. 
Les valeurs sont a leur tour des hachages qui associent, a chaque nom de 
port, un tableau contenant le nom de bloc pouvant servir de Sonde pour 

3 0 observer les signaux de ce port et le nom de la classe C++ correspondante. 

Ce hachage informe le systeme Configurateur sur le type de Composant 
capable d'observer les signaux d'un port donn§ et le type d'API C++ pouvant 
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etre utilisee pour analyser le flux de controle et de donnees observe sur ce 
port. 

La procedure &GenDest accepte en entree le label du composant 
source, son type et son port. Le r6sultat retourne est un hachage qui associe 
5 le label du composant cible connecte avec son port. 

Pour controler la coherence de la configuration generee quel que soit 
I'ordre de prise en compte des Composants, le systeme Configurateur 
appelle la procedure &GenDest avec les parametres obtenus pour le 
composant cible utilise comme source et verifie que le resultat correspond 
10 bien au composant et port source initial. 

Le systeme Configurateur appelle la procedure SGenDest pour 
chaque composant contenu dans le fichier de configuration en parcourant 
tous ces ports. 

Le hachage retourn§ par &GenDest peut contenir plusieurs 
15 composants avec leurs ports respectifs. C'est le cas notamment des 
connexions de type " bus " - SGenDest retourne tous les composants 
connectes par les bus sauf celui qui est donne en argument. Le systeme 
Configurateur insure automatiquement le composant « bus » necessaire., 

Le hachage %moduleToCppClassMap est un accelerateur de 
2 0 recherche permettant de retrouver la classe C++ a partir du nom de module 
de type HDL - 11 ne s'applique qu'aux Modeles elementaires (voir 1.14). 

Le hachage %classCppProtoMap decrit la generation des 
constructeurs d'objets de classes C++, Chaque entree correspond au nom 
d'une classe C++. Chaque description est un hachage compose de quatre 
25 entrees : 

- L'entree "Prea" correspond ci la generation de la premiere partie du 
constructeur (classe nom de Tinstance, premiers parametres). 

- L'entree "Iter" correspond a la partie iterative des parametres du 
constructeur. Cette regie est appliquee pour chaque element contenu 

30 dans Tentree CfgCpp de la description du composant 
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- L'entree "Post" correspond a la partie finale du constructeur (derniers 
parametres parenthese fermante). 

- L'entree "Idle" est une regie de substitution pour la regie "Iter" pour les 
connexions non existantes (configurations partielles). Typiquement, un 

5 pointeur nul ou une chame nulle est genere(e). 

Chaque entree est une chame de caracteres contenant des selecteurs 
speciaux predetermines, substitues par les valeurs calculees par le systeme 
Configurateur. Ces selecteurs ont la forme generate #<Src|Dst|Act><ltem># 
10 ou 'Src\ 'Dsf et 'Act' indiquent Tinstance a prendre en compte , cette 
derniere etant transmise comme parametre a un constructeur d'un objet 
HLL : 

- 'Src* indique Tinstance courante. 

- 'Dsf I'instance connect6e a Tautre extremite du port. 

15 - 'Act' indique I'instance composee correspondant au 

Composant Actif contenant le port d'observation. 

<ltem> est un mot-cle indiquant la selection : 

- 1nsf pour le nom d'instance cpp. 

20 - Mid* pour le label de composant correspondant a Inst. 

" 'let* pour le type de composant (DUT. VERIFIER. XACTOR, 
Monitor...). 

- Port' pour le nom du port. 

Les deux variables "$cpp_preamble" (cf. 3 de A5), "$cpp_postambr 
2 5 (cf. 4 de A5) contiennent respectivement le debut et la fin du texte de 
programme C++ genere par le systeme Configurateur. Le texte genere a 
partir du tableau %classCppProtoMap est insere au milieu. 

Les deux variables "$top_venlog_preamble" et 
"$top_verilog_postamble" contiennent respectivement le debut et la fin du 
30 texte de Tinstance 'top' de la description de type HDL (VERILOG) de la 
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configuration. Typiquennent, ce sont les instanciations des blocs d*horloge et 
autres blocs niveau systeme. 

La description qui suit est un exemple simple de generation de 
5 Configuration par la mise en oeuvre du systeme Configurateur qui est 
illustree dans le cas simplifie ci-apres de I'architecture d'un Systeme 
constitue d'un pont (BRIDGE) reliant une unite centrale (CPU), une Memoire 
et une carte entree/sortie (I/O). L'Architecture du Systeme est representee 
sur la figure 1. 

10 Dans cet exemple, le CPU et le BRIDGE peuvent etre modelises, soit 

par un modele VERILOG du projet "Design" (DUT, DUT_Core), soit par un 
modele compose C++ (XACTOR). 

L'interface entre le CPU et le BRIDGE est nommee FBUS. Plusieurs 
variantes de cette interface sont considerees correspondant a des etapes 
15 successives de developpement. 

Le bloc global Clock assure la distribution des signaux d'horloge et 
signaux systeme globalement pour Tensemble des Composants 

Le systeme Configurateur s'appuie sur la description des Interfaces de 
type HDL des Composants. Des interfaces simples, ecrites en langage 
2 0 VERILOG, sont proposees ci-dessous a titre dlllustration pour chacun des 
Composants. Le systeme Configurateur n'analyse que cette partie des 
fichiers source contenus dans la bibliotheque des fichiers sources de type 
HDL (BFSHDL). lis sinscrivent dans une methodologie de prise en compte 
progressive de variantes de modeles au fur et a mesure de leur disponibilite. 

2 5 La description de type HDL des Interfaces qui suit est reduite a ce qui 

est necessaire a I'illustration des possibilites . et du fonctionnement du 
configurateur. Dans une situation reelle sont indues les descriptions des 
comportements comme dans le cas du modele de Thorloge (module 
CLOCK). 

3 0 La description est la suivante : 
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CPU : 

a) Le modele DUT de composant CPU (figure 7a) presents un port FBUS 
de connexion avec le BRIDGE ainsi qu'un ensemble de signaux 
Systeme definis ci-apres. 

module cpu ( 

XXadr^dat, 

XXreq, 

XXack. 

// 

elk, 

reset, 

powergood 

): 

inout [63:0] XXadr^dat; 
inout [3:0] XXreq; 
inout [3:0]XXack; 

input elk; 
input reset; 
input powergood; 

endmodule 

b) Le modele XACTOR (figure 7b) consiste en un modele abstrait C++ 
dont rinstance de type HDL est constltuee de celle du Port nomme 
fbus_p. Dans cet exemple, il est suppose que le Port FBUS presente 
une variante nommee FBUSA dans laquelle ies signaux 
bidirectionnels adr__dat ont ete eclates en paires de signaux 
unidirectionnels in (inXXadr_dat) et out (outXXadr_dat). 

module fbus_p ( 

inXXadr_dat, 

outXXadr_dat, 

inXXreq, 

outXXreq, 

inXXack, 

outXXaek, 

// 

elk, 
reset, 

powergood 
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): 

input [63:0] inXXadr_dat; 
output [63:0] outXXadr_dat; 
input [3:0] InXXreq; 
output [3:0] outXXreq; 
input [3:0] inXXack; 
output [3:0] outXXack; 

input elk; 
input reset; 
input powergood; 

endmodule 



c) Le models MONITOR du composant CPU est un modele compose 
permettant le Monitoring de I'interface FBUS. Dans le cas oCi il n'existe 
pas d'adaptateur de port fbus_p dans la configuration, une sonde 
contenant I'instance fbus_probe sera generee (figure 7c). 



module fbus_probe ( 
XXadr_dat, 
XXreq, 
XXack, 
II 

elk, 
reset, 

powergood 

); 

input [63:0] XXadr_dat; 
input [3:0] XXreq; 
input [3:0] XXack; 

input elk; 
input reset; 
input powergood; 

endmodule 



Bloc intermediaires d'adaptation FBUS : 
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Ces blocs realisent I'adaptation d'interface au niveau FBUS dans le 
cas oCi la correspondance point ^ point des signaux est impossible. Le port 
FBUSA est la variante de FBUS dans laquelle les signaux bidirectionnels ont 
§t§ delates en paires de signaux unidirectionnels d'entree (in) et de sortie 
5 (out). 

Le module fbus_xchg (figure 7d) realise radaptation entre ['interface 
FBUS du port fbus_p et celui d'un port FBUSA - la largeur de ['interface peut 
etre parametree de fagon a rendre compte d'evolutions technologiques 
possibles. 

10 

module fbus_xchg ( 

XXadr_dat, 

XXreq. 

XXack, 
15 // 

inXXadr_dat, 

outXXadr_dat, 

inXXreq, 

outXXreq, 
20 inXXack, 

outXXack 

); 

inout [63:0] XXadr_dat: 
inout [3:0] XXreq; 

2 5 inout [3:0] XXack; 

// 

input [63:0] inXXadr_dat; 
output [63:0] outXXadr_dat; 
input [3:0] inXXreq; 

3 0 output [3:0] outXXreq; 

input [3:0] inXXack; 
output [3:0] outXXack; 

// model body 

35 

endmodule 

- BRIDGE: 

a) Le modele DUT du composant BRIDGE (figure 7e) presente les trois 
40 ports respectifs vers les modeles CPU, MEM et 10 ainsi que les 
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signaux Systeme dellvres par le bloc systeme dedie SYS_BRIDGE et 
par le bloc global CLOCK. 

module bridge ( 
XXadr_dat, 
XXreq, 
XXack, 
YYadr. 
YYdata, 
ZZdata, 
ZZreq, 
ZZack, 
YYctrl. 
clk_2xp, 
clk_2xn, 
clkp, 
clkn, 
reset, 

powergood 

); 

inout [63:0] XXadr^dat; 
inout [3:0] XXack; 
inout [3:0]XXreq; 

output [31:0] YYadr; 
inout [63:0] YYdata; 
output [2:0] YYctrl; 

inout [15:0] ZZdata; 
input [1:0] ZZack; 
output [1 :0] ZZreq; 

input clk_2xp; * 

input Glk_2xn; 

input clkp; 

input clkn; 

input reset; 

input powergood; 

endnnodule 

b) Le modele BRIDGE_CORE (figure 7f) est la variante DUT_CORE du 
composant BRIDGE presentant une interface FBUSA. Ce modele 
tradult la situation ou le modele du controleur d'interface FBUS n'est 
pas disponible. 
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module bridge_core ( 
inXXadr_dat, 
outXXadr_dat. 
inXXreq. 
outXXreq, 
inXXack, 
outXXack, 
II 

YYadr, 

YYdata, 

YYctrl. 

// 

ZZdata. ^ 
ZZreq, 
ZZack, 
// 

clk_2xp, 

clk_2xn, 

clkp, 

clkn, 

reset, 

powergood 

): 

input [63:0] inXXadr_dat; 
output [63:0] outXXadr_dat; 
input [3:0] inXXreq; 
output [3:0] outXXreq; 
input [3:0] InXXack; " 
output [3:0] outXXack; 

output [31:0] YYadr; 
inout [63:0] YYdata; 
output [2:0] YYctrl; 

inout [15:0] ZZdata; , 
input [1:0] ZZack; 
output [1:0] ZZreq; 

Input clk_2xp; 

Input clk_2xn; 

Input clkp; 

Input clkn; 

input reset; 

input powergood; 
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endmodule 

c) Le modele sys_bridge (figure 7g) est le block systeme dedi6 aux 
signaux Systeme du modele Bridge - il est directement alimente par le 
bloc CLOCK. 
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module sys_bridge( 
clk_2xp, 



output 

output 

output 

output 

input 

input 

input 

input 

output 

output 



clk_2xn, 
clkp, 
clkn, 
reset, 

powergood, 
// 

sys_CLK_2X, 
sys_CLK, 
sys_RESET, 
sys^POWER^GOOD 

); 

clk_2xp; 
clk_2xn; 
clkp; 
clkn; 

sys_CLK_2X; 

sys_CLK; 

sys_RESET; 

sys_POWER_GOOD; 

reset; 

powergood; 



clk_2xp = sys_CLK_2X; 

clk_2xn = ^sys_CLK_2X; 

clkp = sys_CLK; 

clkn = ~sys_CLK; 

reset = sys_RESET; 

powergood = sys_POWER_GOOD; 

endmodule 

d) Le modele XACTOR (figure 7h) est un modele abstrait C++ dont 
I'instance de type HDL est constituee de celle des differents ports 
respectivement fbus_p, cmem_p et cio_p vers CPU, MEM et lO. 
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module cmem_p ( 
YYadr, 
YYdata, 
YYctrl, 
elk, 
reset, 
powergood 
): 

output [31:0] YYadr; 
inout [63:0] YYdata; 
output [2:0] YYctrl; 

input elk; 
input reset; 
input powergood; 

endmodule 

module cio_p ( 
ZZdata, 
ZZreq. 
ZZack, 

// 

elk, 
reset, 

powergood 

); 

inout [15:0] ZZdata; 
input [1:0] ZZack; 
output [1 :0] ZZreq; 

input elk; 
input reset; 
input powergood; 

endmodule 
MEMORY : 

Le modele DUT du composant MEMORY (figure 7i) presente les ports 
respectifs vers les modeles'^BRIDGE et CLOCK. 

modele DUT : 

module cmem ( 
YYadr, 
YYdata. 
YYctrl. 
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elk, 
reset, 

powergood 

); 

input [31:0]YYadr; 
inout [63:0] YYdata; 
input [2:0]YYctrl; 

input elk; 
input reset; 
input powergood; 

endmodule 

I/O : 

Le modele DUT du composant I/O (figure 7j) presente les ports respectifs 
vers les modeles BRIDGE et CLOCK. 

modele DUT : 

module cio ( 
ZZdata, 
ZZreq, 
ZZack. 

elk, 
reset, 

powergood 

); 

inout [15:0] ZZdata; 
output [1:0] ZZack; 
input [1:0] ZZreq; 

input elk; 
Input reset; 
input powergood; 

endmodule 

Block Systeme global : 
Ce modele (figure 7k) assure la fourniture des signaux Systeme 
alimentant les blocs systeme dedies a chaque composant. 

module Clock ( 

sys_POWER_GOOD, 
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sys_RESET, 

sys_CLK, 

sys_CLK_2X 

): 

5 output sys_POWER_GOOD; 

output sys_RESET; 
output sys_CLK; 
output sys_CLK_2X; 

10 parameter HALF_PERIOD = 75; // 7.5ns, 66MHz 

parameter RESET_DELAY = 10000000000 ; //1.0ms 
parameter POWER_GOOD_DELAY = 5000000000 ; // 0.5ms 
initial begin; 

sys_POWER_GOOD = 0; 
15 sys_ RESET =0; 

sys_CLK - 0; 
sys_CLK_2X = 0; 

#POWER^GOOD_DELAY sys_POWER_GOOD = 1; 
#RESET_DELAY sys_RESET = 1 ; 
2 0 end 

always begin 

#HALF_PERIOD sys_CLK = ~sys_CLK; 
end 

2 5 always @{posedge sys_CLK_2X) begin 

sys_CLK = ~sys_CLK; 
end 
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endmodule 



Definition des configurations : 

Les variantes de configuration marquent les differentes etapes de 
3 5 verification suivant la dlsponibilit6 des modeles - le systeme Configurateur 
elabore les configurations de fa5on non ambigu# a partir des informations 
topologiques contenues dans le fichier de configuration. 
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La premiere configuration est definie par le fichier de configuration 1 
ci-apres et representee figure 8a : les modeles DUT du CPU et du BRIDGE 
ne sont pas disponibles. 
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Fichier de configuration 1 : 

CPU_0 XACTOR 

CPU_0 MONITOR 

BRIDGE_0 XACTOR 

5 CiVIEM_0 DUT 

CIO_0 DUT 

Le XACTOR CPU partage le port fbus_p avec le IVIONITOR. 

10 La deuxieme configuration est definie par le fichier de configuration 2 

ci-apres et representee figure 8b. 

Le BRIDGE XACTOR est connects au CPU XACTOR par une 
interface de type FBUSA sp§cifiee dans le fichier de configuration par 
I'attribut FBUSA=FBUS_xchg - le systeme Configurateur insere 

15 automatiquement le deuxieme adaptateurfbus_xchg 102. 

Fichier de configuration 2 : 

CPU_0 XACTOR FBUSA=FBUS_xchg 

CPU_0 MONITOR 

2 0 BRIDGE_0 XACTOR 

CMEM_0 DUT 

CIO_0 DUT 

2 5 Le XACTOR CPU partage le port fbus_p avec le Monitor. 

La troisieme configuration est definie par le fichier de configuration 3 
ci-apres et representee figure 8c : le BRIDGE DUT_CORE est connecte au 
CPU XACTOR par une interface de type FBUSA specifiee dans le fichier de 

3 0 configuration par I'attribut FBUSA=FBUS_xchg - le systeme Configurateur 

insure automatiquement le deuxieme adaptateur fbus_xchg 102. 

Fichier de configuration 3 : 

CPU_0 XACTOR FBUSA=FBUS_xchg 
3 5 CPU_0 MONITOR 

BRIDGE_0 DUT_CORE 
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CMEM_,0 DUT 
CIO^O DUT 

Le XACTOR CPU partage le port fbus_p avec le MONITOR. 

5 

La quatrieme configuration est definie par le fichier de configuration 4 
ci-apres et representee figure 8d : le modele CPU DUT est connecte avec le 
modele BRIDGE XACTOR - le systeme Conflgurateur insere 
automatiquement un adaptateur d'interface fbus pour realiser la connexion 
10 antra le CPU DUT et le BRIDGE XACTOR sans mention explicite de ce bloc 
dans le fichier de configuration. 

Fichier de configuration 4 : 

CPU_0 DUT 
15 CPU^O MONITOR 

BRIDGE_0 XACTOR 
CMEM^O DUT 
CIO_0 DUT 

20 

Le Conflgurateur instancie automatiquennent la Sonde fbus_probe pour 
permettre Tobservation de I'lnterface FBUS par le Monitor. 

La cinquieme configuration est definie par le fichier de configuration 5 

2 5 ci-apres et representee figure 8e : tous les modeles DUT sont disponibles. 

Fichier de configuration 5 : 

CPU^O DUT 
CPU^O MONITOR 
30 BRIDGE^O DUT 

CMEM^O DUT 
CIO_G DUT 

Le systeme Conflgurateur instancie autonnatiquement la Sonde 

3 5 fbus_probe pour permettre Tobservation de Tinterface FBUS par le Monitor. 
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La sixieme configuration est definie par le fichier de configuration 6 ci- 
apres et representee par la figure 8f : c'est une Configuration Multi-serveur - 
la Configl est repartie entre les 2 serveurs SERVER1 et SERVER2. la 
coupure se faisant au niveau de Tinterface FBUS. 

5 

Fichier de configuration 6 : 

CPU_0 XACTOR SERVER1 
CPU_0 MONITOR SERVER1 
BRIDGE^O XACTOR SERVER2 
10 CMEM^O DUT SERVER2 

CIO„0 DUT SERVER2 

Les regies de connectivite pernnettant la generation des tables de 
connectivites et de toute configuration pour cet exemple sent decrites en 
15 langage PERL dans les annexes A1 a A5. 

Uannexe A1 decrit. dans le cas de i'exemple choisi, les regies 
topologiques liees aux composants actifs a utiliser par le systeme 
Configurateur. 

2 0 L'annexe A2 decrit les regies topologiques liees aux Blocs systemes 

et aux Blocs Internnediaires a utiliser par le systeme Configurateur. 

Uannexe A3 decrit les procedures de connexion des Composants a 
utiliser par le systeme Configurateur. 

L'annexe A4 decrit le code de generation du fichier en langage de type 

2 5 HDL (Verilog_top.v) de connexion des composants a utiliser par le systeme 

Configurateur. 

L'annexe A5 decrit le code de generation des Classes C++. 
Les annexes A6 et A7 decrivent les fichiers resultats generes par le 
systeme Configurateur respectivement en langage bas niveau de type HDL 

3 0 (VERILOG) et en langage haut niveau (C++) pour constituer le modele de la 

configuration definie par la troisieme configuration correspondant a la figure 
8c. Le configurateur peut ainsi, avec I'utilisateur-developpeur, realiser son 
modele selon la variante de configuration choisie. 
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On aurait pu, de la meme fagon, illustrer les autres variantes de 
realisation du modele (figures 8a. 8b et 8d ^ 8f) qui pourralent etre traltees 
par le systdme Configurateur pour produire les fichlers resultats 
correspondants, constltuant les modeles de singulation de I'architecture 
systeme envisagee pour le circuit Int6gr6 en developpement. 

La figure 2 repr§sente les divers moyens mis en oeuvre par un 
systeme informatique 40 mettant en ceuvre le procede de Tinvention. 

Le calculateur 40 comporte une unite centrale 41, comprenant des 
circuits de traitement de donnees 42 (unite de traitement arithmetique ALU et 
memoires de programmes associ§s, globalement appeles, par ia suite, ALU, 
par commodite), et comporte diverses memoires, de programmes bu fichlers 
de donnees d'exploltation, assocl6es a I'unlte centrale 41. 

L'unlte centrale 41 comporte une memoire 51 contenant la table de 
composants et de regies de connexions (TCRC), la table de regies de 
coherence de connexions (TRCOH) et la table de formatage de fichlers 
source (TFMT). Ces tables sont creees a partir du fichler de description 
d'archltecture (FDARCH). 

La memoire 51 contlent aussi des programmes ou moteurs inteiligents 
PROGCONF necessaires pour constituer le systeme Configurateur 
exploitable par I'ALU 42. 

Une memoire 53 contlent la table de connexion des instances 
(TCINST) representant les instances des composants et leurs 
interconnexions mutuelles requises par la Configuration definie dans le 
fichier de configuration FCONF et conformes au regies contenues dans les 
tables TCRC et TRCOH. 

La memoire 53 contlent aussI la table de c§blage (TCAB) representant 
les connexions physiques (flls) entre les parties de type HDL des 
composants instancies a partir de la bibllothdque de fichlers sources de type 
HDL (BFSHDL). 

II eh resulte les fichlers MGHDL et MGHLL representant 
respectivement les fichlers sources du modele global de simulation de type 
HDL (VERILOG ou VHDL) et de type HLL (C++) generes par le systeme 
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Configurateur, modele permettant la co-simulation d'un circuit ASIC dans son 
environnement de verification. 

La mise en oeuvre du procede de Tinvention va maintenant etre 
exposee. 

Le procede d'etablissement automatique, au moyen du calculateur ou 
systeme de traitement de donnees 40, de modele de simulation d'une 
configuration de modeles de composants determines, mutuellement relies 
par des connexions d'inter-fonctionnement, pour constituer un modele global 
de simulation MGHDL / MGHLL d'un circuit ASIC dans son environnement 
de verification, comporte les etapes suivantes (cf. figure 2a) : 

- un operateur, eventuellement aide ou meme remplace par un 
calculateur. etablit le fichier de description d'architeqture 
(FDARCH) decrivant les regies d'interconnexion entre les differents 
composants, les modeles pouvant etre utilises pour mod6liser 
chacun de ces composants et les regies de formatage -pour 
generer les fichiers source du modele resultant. v 

- un operateur, eventuellement aide ou meme remplace par un 
calculateur, etablit la bibliotheque BFSHDL de fichiers source, de 
parties de type HDL de modeles de composants respectifs 
susceptibles d'etre utilises dans une configuration conformement 
au contenu du fichier FDARCH. 

- I'operateur etablit le fichier FCONF de configuration visee, 
identifiant les composants et les modeles voulus (cf. figure 2b). 

- Le systeme de traitement lit le fichier de description d'architecture 
(FDARCH) genere et g6nere et place en memoire les tables 
TCRC, TRCOH et TFMT a partir de FDARCH (cf. figure 2b). 

- Les diverses tables TCRC, TRCOH et TFMT etant rendues 
accessibles au systeme de traitement de donnees 40 (cf, figure 
2c), 
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- le systeme de traitement de donnees 40 lit le fichier de la 
configuration visee FCONF pour identifier les connposants et leurs 
nmodeles requis (cf. figure 2c), 

- if lit la table de composants et de regies de connexion pour 
5 instancier et placer dans la table de connexion des instances 

TCINST les composants requis (cf. figure 2c). 

- II lit la table de regies de coherence de connexions (TRCOH) pour 
verifier la connectivite physique entre modeles et inserer, le cas 
echeant, des composants intermediaires. 

10 - II lit dans la bibliotheque BFSHDL les fichiers source 

correspondents aux parties de type HDL des modeles de 
composants instancies dans la table TCINST pour engendrer la 
table TCAB de connexions physiques (fils) entre les modeles de 
composants (cf. figure 2c). 

15 - II applique les regies de formatage de la table TFMT au contenu 

des tables TCINST et TCAB et il genere les fichiers source finaux 
MGHDL/MGHLL de module global de simulation correspondent a 
la configuration specifiee par le fichier de configuration (FCONF) 
(cf. figure 2d). 

20 

Le fichier d'entree FCONF correspond done a une description du 
schema theorique du type de la figure 1 , sans toutefois les modeles, qui sont 
ajoutes lors de Telaboration des tables intermediaires TCINST, TCAB 
descripteurs de configuration et de connexions, afin de fournir un modele 

2 5 global de simulation qui soit effectivement op^rationnel et qui, en outre, ici, 

permette une observation de signaux particuliers. 

Les diverses tables ci-dessus peuvent etre prealablement stockees 
dans le calculateur 40 ou bien avoir ete stockees dans une memoire externe 
que Ton relie au calculateur 40, eventuellement par un reseau de 

3 0 transmission de donnees pour qu'elles lui soient accessibles. 
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L'ALU 42 dispose alors de toutes les donnees de base necessaires 
aux tables outils TCRC, TRCOH, TFMT pour que le programme 
PROGCONF associe au systeme Configurateur, commande, a TALU 42, 
relaboration des fichiers finaux MGHDL/MGHLL (cf. figure 2d). 

La table intermediaire TCAB. des descripteurs de connexions 
physiques, generee ici a partir d'une description de type HDL, est, dans cet 
exemple, soumise a une verification, afin de detecter des erreurs manifestes, 
telles que Texistence d'entrees ou sorties non raccordees ou encore de 
sorties reliees en parallele, lorsqu'il s'agit de sorties classiques de type dit 
*totem\ done autres que celles a coilecteur ouvert ou a inhibition commandee 
(tri-state). 

En cas de modification du fichier de depart FCONF, les .tables 
intermediaires TCINST. TCAB et les fichiers finaux MGHDL/MGHLL peuvent 
ainsi §tre redefinis a partir des fichiers sources de modeles et de fichier 
FDARCH. On evite ainsi des risques d'erreur a 

Dans cet exemple, TALU 42 genere un modele global de co-simulation 
en associant, a au moins un bloc fonctionnel, plusieurs modeles de 
specification fonctionnelle ecrits en langages de programmation de niveaux 
differents, ici de type HDL et C++. 

On conceit que la presente invention peut etre mise en oeuvre selon 
d'autres formes specifiques, sans sortir de son domaine d'application tel que 
revendique. Par consequent, la presente description detaillee doit etre 
consideree comme etant une simple illustration d'un cas particulier dans ie 
cadre de Tinvention et peut done etre modifiee sans sortir du domaine defini 
par les revendications jointes. 
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ANNEXE : Description du code Conf igurateur 
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Al - Regies Topologiques liees a\ix Composants actifs 

# ! /usr/triton/bin/perl 

############################################################## 

################# 

# 

# Copyright (c) 2000 BULL - Worldwide Information Systems 

# All rights reserved 
# 

# Module name : patent__conf ig__def s .pm 

# Author : Andrzej Wozniak 
# 

################# 
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### 

%Ac t i vi ty_TypeMap = 



( 



"XACTOR" 
" DUT " 

"DUT_CORE " 
"MONITOR" 
"IND_CON" 
"SYS_CON" 

) ; 



=> "actor", 
=> "actor", 
=> "actor", 
= > " spectator " , 
=> "helper" , 
=> "helper" , 
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################## 
%lns tNameModu 1 eMap s 
################## 
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liste de's labels CPU acpeptes 



( 

####### 

"CPTJ" => 
####### 

{ "MatchExpr" => " ^ (CPU) (? :_ [0 -3 ] ) \$ " , 
"ExtrExpr" => " ''CPU_ ( [0-3 ] ) \$ " , 
#### 

"DUT" => 

{ "ReqModule" => { "cpu" => "cpu_model . v" , 
). 



expressions regulieres de connexion 



"Connect"- => { FBUS => [\&subst_inf ix, ["(XX.*)", 
"Port" => { FBUS => [CPU__a, cpu, 0], }, 



M. 
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"genDest" => X&genDest, 

"SysConn" => { CPU_a => \@std_glob_con, 

"CfgCpp" => [CPU_Dut, [ ['Own', [CPU_a , DUT, ], 
5 ' ['None'] A 



CPU_a = nom logique . , " 

. cpu" = nom "de X' 'instance, Vefl log generee 

0 = n^ de'port' / ^ ' 

\&genDest „= def init la procedure generant 
: ie- genDest - * ^ -Li,''/--, ^--r-^, -^-^rL 



"XACTOR" => 

15 { "ReqModule" => ( "fbus_p" => " f bus_port . v" , 
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^ " meme nom de'^'cpnneicion^ 
de part /et " d"' autre ' 



"Connect" => { "FBUSA" => [\&subst__inf ix, 

["in( . *) " , "aa_con"] , ["out (.*)", "bb_con"] , ] , 



iUGldiilrieSiiiE^^ " tjet^l-H&iedHe 



"SelfConnect" => { "FBUSA" => [\&:subst__inf ix, 
["out (.*)", "aa_con"] , ["in( .*) ", "bb__con"] , ] , 

3 0 "Port" => { FBUSA => [FBUS_p, fbus_p, 0], }, 

"genDest" => X&genDest, 

"SysConn" => { FBUS_p => \(S>std__glob_con, 
). 

"CfgCpp" => [CPU_Xactor, [ [ ' Src ' , [FBUS_p , 
3 5 FBUS_type, Fbus__hwif] , ' [FBUS] ] ] ] . 

"MONITOR" => 

{ "ReqModule" => { "fbus_p" => " f bus_pbrt . v" , 
40 } , 

"Connect" => { "FBUS" => [\&:subst_inf ix, 

["in ( . *) " , "aa_con"] , ["out (.*)", "bb_con"] , ] , 

45 "SelfConnect" => { "FBUS" => [\&subst_inf ix, 

["out ( . *) " , "aa_con" ] , ["in ( . *) " , "bb_con"] , ] , 

"Port" => { FBUS => [FBUS_p, fbusjp, 0], }, 
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"genDest" => \ScgenDest, 

"SysConn" => { FBUS_p => \@std_glob_con, 

"ProbeConnect " => { FBUS => Fbus_hwif, 

5 }, 

"CfgGpp" => [CPU_Monitor, [ ['Mon', [FBUS_p , 
FBUS_type, Fbus_hwif ] , [FBUS] ,],],], 

)> 

10 #### 

},### CPU 

###### 

"BRIDGE" => 
###### 
15 { 

"MatchExpr" => ""^ (BRIDGE) (? :_[0-l] ) \$" , 

"ExtrExpr" => " ^BRIDGE_ ( [0 -1] ) \$ " , 
#### 

" DUT " = > 

20 { "ReqModule" => {"bridge" => "bridge_x. v" , 

"Connect" => { FBUS => [\&subst_inf ix, ["(XX.*)", 



" " ] , ] 
25 ""].] 
" " ] , ] 



CMEM => [\&subst_inf ix, ["(YY.*)", 
CIO => [\&subst infix, ["(ZZ.*)", 



30 "Port" => { FBUS => [BRD, bridge, 0] , 

CMEM => [BRD, bridge, 1] , 
CIO => [BRD, bridge, 2] , 

}. 

35 "genDest" => X&genDest, 

"SysConn" => { BRD => [ \&getSpecSysInst , "E", 
[\&subst_inf ix, ["(.*)",""],],], 

"CfgCpp" => [Bridge_Dut, [ ['Own', [BRD, DUT, ], 
4 0 [ ' None ' ] , ] , 

] , 

] , 

]. 
#### 

4 5 "DUT_CORE" => 

{ "ReqModule" => { " br idge_core " => "bridge_core . v" , 
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"Connect" => { FBUSA => [\&subst_inf ix, 
[" (XX. *) " , " "] , ["in( . *) " , "aa_con"] , ["out (.*)", 
"bb_con"] , ] , 

CMEM => [\&:subst_inf ix, ["(YY.*)", 

5 

CIO => [\&:subst_inf ix, ["(ZZ.*)", 

10 "Self Connect " => { "FBUSA" => [\&subst_inf ix, 

["out (.*) "aa__con"] , ["in(.*) "bb_con"] ,] , 

"Port" . { FBUSA => [BRD, bridge_core, 0] , 

15 CMEM => [BRD, bridge_core, 1] , 

CIO => [BRD, bridge_core, 2] , 

). 

"genDest" => X&genDest, 
20 . "SysConn" => { BRD => [XScgetSpecSysInst , "E", - 

[\&:subst_inf ix, t "(.*)","" 1 , 1 J , 

"CfgCpp" => [Bridge_Dut, [ ['Own', [BRD, 
DOT_CORE, ], ['None'], ], 
25 1 , 

3 , 

}, 

#### 
"XACTOR" => 

30 { "ReqModule" => { "fbus_p" => "fbus_port . v" , 

"cmem__p" => "cTnem_port . v" , 
"cio_p" => "cio_port . V" , 

"Connect" => { FBUSA => [\&subst_inf ix, ["in(.*)" 
35 "aa_con"] , ["out ( . *) " "bb_con"] , ] , 

CMEM => [\&subst_inf ix, ["(YY.*)", 

" "] ,] , 

CIO => [\ScSubst_inf ix, ["(ZZ.*)", 

40 } , 

"Self Connect " => { "FBUSA" => [\ScSubst_inf ix, 
["out "aa_con"] , [ " in ( . " , "bb__con" ] , ] , 



45 



"Port" => { FBUSA [FBUS__p, fbus_p, 0] 

CMEM => [CMEM_p, cmem_p, 1] , 
CIO => [CIO__p, cio_p, 2] , 



1 er depot 

56 



"genDest" => \&genDest, 

"SysConn" => { FBUS_p => \@std_glob_con, 
5 CMEM_p => \@std_glob__con, 

CIO_p => \@std_glob_con, 

}, 

"CfgCpp" => [Bridge_Xactor, [ [ ' Src • , [FBUS_p, 
FBUS_type, Fbus_hwif] , [FBUS] ] , 
10 ['Src', [CMEM_p, CMEM_type, 

Cmem_hwif ] , [CMEM] ] , 

['Src', [CIO_p, CIO_type, 

Cio_hwif] , [CIO] ] , 

] , 

15 ] , 

#### 

###### 
20 "CIO" => 

###### 

{ - " • 

"MatchExpr" => " ^ (CIO) ( ? :_ [0 - 1] ) \$ " , 
"ExtrExpr" => "^CIO_( [0-1] ) \$" , 
25 #### 

"DUT" => 

{ "ReqModule" -> { "cio" => "cio_model . v" , 

"Connect" => { CIO => [\&subst_inf ix, ^ ["(ZZ.*)", 

30 ""],], 

"Port" => { CIO => [CIOD, cio, 0] , 

35 

"genDest" => \&genDest, 

"SysConn" => { CIOD => \@std__glob_con, 

. . }' 

"CfgCpp" => [Cio_Dut, [ ['Own', ['Src', [CIOD, 
40 DUT, ] , [None] ] , ] , 

] , 

] , 

}. 

#### 

45 "XACTOR" => 

{ "ReqModule" => { "cio_p" => "cio_model . v" , 
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"Connect" => { CIO => [\&subst_inf ix, ["(ZZ.*)", 

■•"],], 

5 "Port" => { CIO => [CIOD, cio, 0] , 

}, 

"genDest" => X&genDest, 

"SysConn" => ( CIOD => \@std_glob_con, 

10 } , 

"CfgCpp" => [Cio_Dut, [ ['Own', [ ' Src ' , [CIOD, 
DUT, 1 , [None] ] , ] , 

] , 

15 ] , 

}> 
}> 

###### 
"CMEM" => 

20 ###### 

"MatchExpr" => " ^ (CMEM) (? :_ [0 - 1] ) \$ " , 
"ExtrExpr" => "^CMEM_( [0-1] ) \$". , 
#### 

25 "DUT" => 

{ "ReqModule" => { "cmem" => "cmem_model . v" , 

"Connect" => { CMEM => [\ScSubst_inf ix, 
["(ZZ.*)", ""],], 
30 } , 

"Port" => { CMEM => [CMEMD, cmetn, 0] , 

], 

3 5 "genDest" => \&genDest, 

"SysConn" => { CMEMD => \@std_glob_con, 

"CfgCpp" => [Cmem_Dut, [ ['Own', ['Src*, [CMEMD, 
40 DUT, ] , [None] ] , ] , 

] , 

] , 

}. 

#### 

4 5 "XACTOR" => 

■ { "ReqModule" => { "cn\em_p" => " cmem_model . v" , 
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"Connect" => { CMEM => [\&subst_inf ix, t"(ZZ.*) 

"Port" => { CMEM => tCMEMD, cmem, 0] , 
}> 

"genDest" => X&genDest, 

"SysConn" => { CMEMD => \@std_glob_con, 

"CfgCpp" => [Cinetn_dut, [ ['Own', [ • Src ' , [CMEMD, 
DUT, ] , [None] ] , ] , 

] , 

1 , 

} 

) ; 
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%PortProbeMap = 
( 

' cpu ' = > { 

"FBUS" => [ " FBUS_PROBE " , Fbus_hwif ], 

) ; 

###### 

1 ; ### makes perl happy 
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ANNEXE 

A2 - Regies Topologiques liees aux Blocs systeme et blocs 

intermediaires 

# ! /usr/triton/bin/perl 
5 ######################################################### 
###################### 
# 

#* Copyright (c) 2000 BULL - Worldwide Information 

Systems 

10 # All rights reserved 

# 

# Module name : patent_sys_conf ig_def s . pm 

# Author : Andrzej Wozniak 

# 

15 # Description : tables for driving configuration 

# generation aux part 
# 

# Rev Date : $Date : 2001-03-06 19:11:20+01 $ 

# • 

20 ######################################################### 
###################### 
######### 

$GlobSysInst = 'SysClock'/ 

$GlobSysInstModule = 'Clock' ; 
25 $GlobSysInstModuleSrc = 'patent_sys_glob.v» ; 

# Factorisation de 1' expression commune S 1' ensemble des 

connexions aux Blocs Globaux 
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@std_glob_con = ( X&getGlobSysInst , "E", 
3 0 [\&:subst_inf ix, 

["-^ (? :clk) \ $" , "sys_CLK_2X"] , 

["^ (?: reset) \$" , "sys_RESET"] , 

["^ (? :powergood) \$", " sys_POWER_GOOD" ] , 

] , ) ; 



####### 



%Hwf Connect ivityMap = 

( 

"bridge" => { 
40 "cpu" => "Direct", 

"cmem" => "Direct", 
"cio" => "Direct", 

- "fbus_p" => "fbus_xchg", 

"fbus_xchg" => { FBUS => 'Direct', 
45 }, 



2 dfe A2^ 
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10 



"bridge_core" => { - 

" cpu " = > " f bus_xchg " , 

"cmem" => "Direct", 
"cio" => "Direct", 

"fbus_p" => "Direct", 
"fbus_xchg" => { FBUSA => 'Direct' 
FBUS ' f bus__xchg » , 



"fbus_p" => { 

"fbus_xchg" => { FBUSA => 'Direct*, 
FBUS => 'fbus_xchg', 

15 "cpu" => "fbus_xchg", 

"fbus_p" => 'Direct', 

). 

"cio" => { "cio__p" => 'Direct' }, 
20 "cmem" => ( "cmem_p" => 'Direct' }, 

"fbus_xchg" => { "fbus_xchg" => { FBUS => 'Direct' }, 
"cpu" => { "fbus_xchg" => { FBUS => 'Direct' }, 

}\ 

25 ) ; 

####### 

%Hwi£AltemateMap = 

( 

} ; 

30 ### 

%SysWrapMap = 

( 

bridge => [ BRIDGE_sys, sys_bridge ] , 

bridge_core => [ BRIDGE_sys, sys_bridge ] , 

35 ) ; 

####### 



%SysConnectMap = . 3 de A2 

( ' 
40 ###### 

"$GlobSysInst" => 

###### 

{ "MatchExpr" => " * ($GlobSysInst ) \$ " ,, 
"ExtrExpr" => ($GlobSysInst) \$" , 
45 #### 

"SYS_CON" => 

{"ReqModule" => { " $GlobSysInstModule " => ' 
"$GlobSysInstModuleSrc" , 
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"Connect" => { "Global" => [\&subst_inf ix, 
["(.*)",""],], 

}. 

}. 

}, #### $GlobSysInst 
###### 

"BRIDGEsys" => 
###### 

{ "MatchExpr" => " ^ (? : BRIDGE_ [0-3 ] _) (sys) \$" , 
"ExtrExpr" => "^BRIDGE_( [0-3] )_sys\$" , 
#### 

"SYS_CON" => 
{ "ReqModule" => 

{ " sys_bridge " => " sys_bridge . v" , 

"Connect" => { BRIDGE_a => [\&subst_inf ix, 

"SysConn" => { BRIDGE_a => [\&getGlobSysInst , "E", 
[\&subst__inf ix, ["sys_(.*) ",""],],], 

"SysWrap" => { BRIDGE^a => [\&subst_inf ix, 
["syswrap_(.*) , ] , 

#### 

# Construction des noms des Blocs Systemes dedies 
a un Composant et 

# verification de la connectivite des interfaces 
entre les Blocs Systeme et 

, # leurs Composants dedies 
"getOwnDest" => X&getSpecSysOwn, 
"genVlog Inst Parameter" => r-^ 
\ &gen_sys_Vl oglnst Parameter , >^ 
#### 



}, #### BRIDGE_sys 
) ; 

### 

%SysSpecMap = 

( 

###### 

"FBUS_XCHG" => 
###### 



#i Variables faxsant' reference 
a un" code^ generique" 'commuh 
pour 1*'. erisemtire des projets 
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{ "MatchExpr" => " ^ (?:.*_) (FBUS__XCHG) \$ " , 
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"ExtrExpr" => (?:.*) ( [0-3] ) _FBUS_XCHG\$" , 

"BaselidExpr" => " ^ . * (FBUS__XCHG) \$ " , 
### 

"IND_CON" => 
5 { "ReqModule" => 

{ " f bus_xchg " = > " f bus_xchg . v " , 

}. 

"Port" => { "FBUS" => ["FBUS_xchg" , "fbus_xchg", 

10 0] , 

" FBUSA " = > [ " FBUS_xchg " , " f bus_xchg " , 1 ] , 

"Connect" => { "FBUS" => [\&:subst_inf ix, 
["(XX.*)", ""],], 
15 "FBUSA" => [\&subst_inf ix, ["in(.*)", 

"aa_con"] , ["out{.*)", "bb_con"],], 

"SelfConnect" => { "FBUS" => [\&subst_inf ix, 
["(XX.*)", ""],], 
20 "FBUSA" => [\&:subst_inf ix, 

["out(.*)", "aa_con"], ["in(.*)", "bb_con"],], 

}. 

"genOwn" => \ScgenOwnSysSpecMapGeneric, 

"getOwnDest" => \&getSpecSysOwn, 

25 

"CfgCpp" => [Fbus_Xchg, [ ['Own', [fbus_xchg, 
IND_CON, ] , [ 'None ' ] , ] , 

] , 

] , 

30 } , 

), 

###### 

'PBUS_PROBE' => 
###### 

35 { "MatchExpr" => " ^ ( . * ) (FBUS_PROBE) \$ " , 

"ExtrExpr" => " ^ . *? ( [0 - 3 ] ) . *FBUS_PROBE\$ " , 
" Basel idExpr" => ( . * ) _FBUS_PROBE\$" , 
#### 

"PROBE" => 

4 0 { "ReqModule" => { " f bus_probe " => "fbus_probe . v" 

]. 

"Connect" => ("FBUS" => [\&subst_inf ix, ["(.*)", 
■"• ] , ] , 

45 "Port" => { "FBUS" => [ " FBUS_probe " , 

" f bus__probe" , 0], 

}. 

"SysConn" => { "FBUS_probe" => \®std_glob_con. 



# 
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"genVloglnst Parameter" => 
\&:gen_sys_VlogInstParameter_Generic, 

}. 

) ; 
### 

%indTypeCf tpMap = 

( 

10 " FBUS_xchg " = > " FBUS_XCHG " , 
" f bus_xchg " = > " FBUS_XCHG " , 
) ; 



5 ■ de A2 



15 



20 



25 



30 



re 



RESET ] , 
POWER_GOOD ] , 
CLK_33MHz ] , 

CLK 66MHz ] , 



### 

©sysGlobConnTab = 

( 

[ sys_RESET 
[ sys_POWER_GOOD 
[ sys_CLK 
[ sys_CLK__2X 

) ; 
### 

%SysPinConst = 

( 

" $GlobSys Inst " = > \@sysGlobConnTab , 
CPU_sys => \@sysGlobConnTab, 
CMEM_sys => \@sysGlobConnTab , 
CIO__sys => \@sysGlobConnTab, 
BRIDGE_sys => \@sysGlobConnTab, 
BRIDGE => \@sysGlobConnTab, 
).; 



f e r enc e par % Sy s inCon s t 
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##### 

sub gen_sys_VlogInst Parameter { 

3 5 my($inst, $cat, $Cftp, $i_map) = @_; 

($Cftp, $i_map) = getCf tp {$inst) unless $Cftp and 
$ i_map ; 

my($extr) = $ { $i_map} { $Cf tp} { ' ExtrExpr ' } ; 
$inst $extr; 

4 0 my ( $Modul e_num , $Node_num , $ SubNode_num) = ( $ 1 , $ 2 , $ 3 , 

$4); 

my ( $parent_inst , $parentj_cf tp, $parent_map) = 
&:get_parent___inst ($inst ) ; 
my ( $num_add) = 0 ; 
45 $num__add - $ ( $parent_map} { $parent_cf tp} { 'NumAdd' } , 

$Node_num += $num___add 

if exists $ { $parent_map} { $parent__cf tp} ( 'NumAdd' } ; 
my ($parameter) = " " ; 
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foreach $pp ($Module_num, $lsrode_num, $SubNode_num) { 
$parameter "/ " if $parameter ne and $pp =- 
/\d+/; 

$parameter .= $pp if. $pp. =- /\d+/; 

5 } 

my ($conn_mask) = 
&get_parent_inst_connected_mask ($inst) ; 
if ($conn_mask ne " " ) { 

$parameter .= "if $parameter ne ""; 
10 $parameter .= $conn_Tnask; 

} 

if ( $parameter ) ( 

return "# ($parameter) 

} . . 

15 return "" 

} 

####### 

1; ### makes perl happy 
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ANNEXE 

A3 - Procedures de connexion des Composants 

# 1 /usr/triton/bin/perl 

######################################################### 
5 ###################### 
# 

# Copyright (c) 2000 BULL - Worldwide Information 
Systems 

# All rights reseirved 
10 # 

# Module name : patent_connect_def s . pm 

# Author : Andrzej Wozniak 
# 

# Description : connection generation 
15 # 

# Revision : $Revision: 1.1 $ 
# 

# Rev Date : $Date : 2001-01-29 20:19:10+01 $ 

# 

20 ######################################################### 
###################### 
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#### 

sub genDest { 

25 my($inst, $extExpr, $srclfc) = ®__; 

my (%dest) = () ; 
my ($dft) ; 

unless ( $inst /$extExpr/ ) { 
&dpr:int__conf ig_error ( "genDest " , 
3 0 "number extracting expression \"$extExpr\" 

failed for $inst\n"); 

return (\%dest, $dft) ; 

while ( $inst /$extExpr/ ){ 
35 $nl = $1; 

$n2 = $2 ; 
$n3 = $3/ 
my($nb) = 0; 

if($inst $InstNameModuleMap{CPU}{"MatchExpr"}) { 
40 ## CPU 

%dest = ("BRIDGE_$nl" => "FBUS"), 
$dft = "BRIDGE", 

last if $srclfc /"FBUS [A-Za-z0-9_] */ ; 
goto label_error; 

45 } 

if ($inst $ I nstNameModuleMap{ BRIDGE} { "MatchExpr" } ) { 
## BRIDGE 
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%dest = ( "CPU_$nl" => "FBUS"), 
$dft = "CPU", 

last if $srclfc =^ /FBUS/; 
%dest = ( "CMEM_$nl" => "CMEM"), 
5 $dft = "CMEM", 

last if $srclfc /CMEM/ ; 
%dest = ( "CIO_$nl" => "CIO"), 
$dft = "CIO", 
last if $srclfc /CIO/; 
10 goto label_error; 

} 

if($inst $InstNaTneModuleMap{CMEM} { "MatchExpr" } ) { 
## CMEM 

%dest = {"BRIDGE_$nl" => "CMEM"), 
15 $dft = "BRIDGE", 

last if $srclfc /^CMEM$/; 
goto label_error; 

} 

if($inst $InstNameModuleMap { CIO} { "MatchExpr" }) { 
20 ## CIO 

%dest = ( "BRIDGE_$nl" => "CIO"), 
$dft = "BRIDGE", 
last if $srclfc /'^CIO$/; 
goto label_error; 

25 } 

&dprint_conf ig__error ( "genDest " , "unknown instance 
$inst") ; 
last ; 
label_error : 

30 &:dprint_conf ig_error ( "genDest " , "unknown interface 

$srclfc for instance $inst"); 
last; 

} 

return {\%dest, $dft) ; 
35 } 

####### 

1 ; ### makes perl happy 
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ANNEXE 

A4 - Code de generation du fichier Verilog Top.v de 
connexion des Composants 

# 1 /usr/tri ton/bin/perl 

5 ######################################################### 
###################### 
# 

# Copyright (c) 2 000 BULL - Worldwide Information 
Systems 

10 # All rights reserved 

# 

# Module name : patent__verilog_def s .pm 

# Author : Andrzej Wozniak 
# 

15 # Description : VERILOG strings and defs 

# for generation of top.v source code 

# 

# Revision : $Revisipn: 1.4 $ 
# 

20 # Rev Date : $Date: 2001-02-19 19:55:41+01 $ 

' # 

######################################################### 
###################### 

2 5 @verilog_src_path = 

( 

"$db_dir/patent/sim/models" , 
) ; 

3 0 $top_verilog_header = <<"END_OF_TOP_HEADER" 

///////////////////////////////////////////////////////// 
///////////// 

// FILE \"%s\" GENERATED by A.W. PERL SCRIPT 
// FROM \"%s\" file 
35 ///////////////////////////////////////////////////////// 
/////////////\n\n 

////// 

"timescale lOOps 
END_OF_TOP_HEADER 

40 

$top_verilog_preainble = <<"END_OF_TOP__PREAMBLE" 

////// 

module top ( ) ; 

45 

wi re POWER_GOOD ; 

wire RESET; 
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wire CLK__33MHz; 
wire CLK_66MHz; 

5 $GlobSysInstModule $GlobSysInst ( 

. sy s_POWER_GOOD ( POWER__GOOD ) 

. sys_RESET (RESET) , 

.sys_CLK (CLK_33MHz) , 

.sys_CLK_2X (CLK_66MHz) 
10 ) ; 
END_OF___TOP__PREAMBLE 

#### 

15 $top_verilog_postainble = «"END_OF_TOP_POSTAMBLE" 

endmodule 



///////////// 
2 0 // END 

///////////// 

END OF TOP POSTAMBLE 



25 ####### 

1; ### makes perl happy 



4i 
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ANNEXE 

A5 - Code de generation des Classes C++ 

#1 /usr/triton/bin/perl 

######################################################### 
5 ###################### 

# 

# Copyright (c) 2000 BULL - Worldwide Information 
Systems 

# All rights reserved 
10 # 

# Module name : patent_cpp_gen_def s .pm 

# Author : Andrzej Wozniak 
# 

# Description : cpp generation tables 
15 # 

# Revision : $Revision: 1.1 $ 
# 

######################################################### 
###################### 

20 

#### 

%moduleToCpPRClassMap s 

( 

fbus_probe => Probe_hwif, 
25 ) ; 

#### 

%classCppProtoMap = 

( 

#### 

3 0 CPU_Dut => 

#### 
{ 

Prea => "static CPU_Dut #SrcInst# 
(LabelClass: :#SrcIid#,.. TypeClass : :#SrcIct#, \n" 
35 . "\t\t\t\tstring(\"#SrcVlogPath#\") ) ;\n", 

}. 

#### 

CPU_Monitor => 
#### 
40 { 

. Prea => "static CPU_Monitor #SrcInst# 
(LabelClass : : #SrcI id# " , 

Iter => " , \n\t\t\t&#DstPort#" , 
Post => " ) ; \n" , 
45 . Idle => " , \n\t\t\t0" , 

). 

#### 



, r2, d'e AS 
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Bridge_Dut => 

#### 

{ 

Prea => "static Bridge_Dut #SrcInst# 
5 (LabelClass : :#SrcIid#, TypeClass : : #SrcIct# , \n" 

. "\t\t\t\tstring(\"#SrcVlogPath#\") ) ;\n" , 

}. 

#### 

Cio_Dut => 
10 #### 
{ 

Prea => "static Cio_Dut #SrcInst# 
(LabelClass: :#SrcIid#, TypeClass : :#SrcIct#, \n" 

. "\t\t\t\tstring(\"#SrcVlogPath#\") ) ;\n", 

15 }, 

#### 

Cmem_Dut = > 

#### 

{ 

20 Prea => "static Cmem_Dut #SrcInst# 

(LabelClass: :#SrcIid#, TypeClass :: #SrcIct# , \n" 

. "\t\t\t\tstring (\ "#SrcVlogPath#\ " ) ) ;\n" , 

}. 

#### 

2 5 CPU_Xactor => 

#### 
{ 

Prea => "static CPU_Xactor #SrcInst# 
(LabelClass: :#SrcIid#", 
30 Iter => " , \n\t\t\t&#SrcPort#" , ' "' 

Idle => " , \n\t\t\t0" , 
Post => ") ;\n" , 

#### 

35 Bridge_Xactor => 

#### 
{ 

Prea => "static Bridge_Xactor #SrcInst# 
(LabelClass: :#SrcIid#", 
40 Iter => " , \n\t\t\.t&#SrcPort#" , 

Idle => " , \n\t\t\t0" , 
Post => " ) ; \n" , 

}. 

#### 

45 Fbus_hwif => 

#### 
{ 
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Prea => "static Fbus_hwif #SrcInst# 
(LabelClass : :#SrcIid#, TypeClass: :#SrcIct#, \n" 

. "\t\t\t\tstring (\"#SrcVlogPath#\") ) ; \n" , 

}, 

5 #### 

Probe_hwif => 

#### 

{ 

Prea => "static Probe_hwif #SrcInst# 
10 (LabelClass: :#SrcIid#, TypeClass :: PROBE, \n" 

. "\t\t\t\tstring(\"#SrcVlogPath#\") ) ;\n" , 

], 

#### 

Cmem_hwi f = > 
15 #### 
{ 

Prea => "static Cmem_hwif #SrcInst# 
(LabelClass: :#SrcIid#, TypeClass: :#SrcIct#, \n" 

. "\t\t\t\tstring(\"#SrcVlogPath#\") ) ;\n", 

20 } , 

#### 

Cio_hwif => 

#### 

{ 

25 Prea => "static Cio_hwif #SrcInst# 

(LabelClass : :#SrcIid#, TypeClass :: #SrcIct#, \n" 

. "\t\t\t\tstring(\"#SrcVlogPath#\") ) ;\n", 

} . 

#### 

30 Fbus_Xchg => 

#### 
{ 

Prea => "static Fbus_Xchg #SrcInst# 
(LabelClass: : #SrcIid# TypeClass : :#SrcIct#An" 
35 . "\t\t\t\tstring(\"#SrcVlogPath#\") ) ;\n", 

) ; 

##### 

$cpp_preaiTible = << "END_OF_PRE AMBLE" 

40 /////////////////////////////////////// 
// FILE GENERATED by A.W. PERL SCRIPT 
// FROM %s file 
// FOR %s 

/////////////////////////////////// ////\n\n 
45 ///////////// 

#include \ " serve r_regis try . hpp\ " 
#include \ " server_components • hpp\ " 



3. de A5 
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/////////////\rAn ■ • 

const string ServerRegistry : :m_serverName = \"%s\"; 
const string ServerRegistry : rtn^conf igName = \"%s\"; 
const int ServerRegistry : : m_serverNumber = %d; 
Status Instant iateConfiguration ( ) \ { 
//////////////\n 
END OF PREAMBLE 



10 #### 

$cpp_postamble = <<"END_OP_POSTAMBLE" 

\treturn Success; \n} 

///////////// 
// END 
15 ///////////// 

END OF POSTAMBLE 



fJ: de A5 



#### 



20 ####### 

1; ### makes perl happy 
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A6 - Fichier Resultat Verilog 



10 



iii/iiiin/iiiiiininf/iiiiiiiiiiiifi//i//ii/iniiinin 
///////////// 

I / FILE "conf ig_server_pat03_top. V" GENERATED by A.W. 
PERL SCRIPT 

// FROM "patent/sim/conf igs/pat03 . cf g" file 

///////////////////////////////////////////////////////// 

///////////// 



15 



III Ml 

"timescale lOOps 
////// 

module top () ; 



wire 
wire 



POWER_GOOD ; 
RESET; 



20 



wire 
wire 



CLK_3 3MHz; 
CLK 66MHz ; 



25 



30 



35 



40 



45 



Clock SysClock{ 

. sys_POWER_GOOD 
. sys_RESET 
. sys_CLK 
. sys_CLK_2X 

) ; 

//////////////////////////////// 
III// Wire Declaration Section 

//////////////////////////////// 



(POWER_GOOD) 
(RESET) , 
(CLK_3 3MHz) , 
(CLK 6 6MHz ) 



// wire 
// wire 
// wire 
// wire 

wire 
output ( 1 ) 

wire 
output ( 1 ) 

wire 
output (1) 

wire 
output ( 1) 

wire 
input (1) 

wire 
output ( 1 ) 



CLK__3 3MHz; 
CLK__66MHz; 
POWER__GOOD ; 
RESET; 



// output (1) 
// input (3) output (1) 
// input (3) output (1) 
// input (3) output (1) 



[3:0] 


Wl_ 


_00_inXXack; 


// 


input ( 1 ) 


[63:0] 


Wl_ 


00_inXXadr_dat ; 


. // 


input (1) 


[3:0] 


Wl^ 


_OO^inXXreq; 


// 


input (1) 


[3:0] 


Wl_ 


0 0_OutXXack ; 


// 


input (1) 


[63:0] 


Wl_ 


_^0 0_outXXadr_dat ; 




// 


output (1) 










[3:0] 


Wl_ 


0 0_outXXr eq ; 


// 


input (1) 
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10 



15 



20 



25 



30 



35 



40 



45 



wire 


[3 : 


0] 


W_ 


_0 0_ 


_XXack; 


// 


inout ( 2 ) 


wire 


[63 


:0] 


w_ 


oo" 


XXadr dat ; 




/ / inc 


wire 


[3 : 


0] 


w~ 


go" 


"xXreq; 


// 


inout (2 ) 


wire 


[31 


:0] 


w_ 


"oo" 


~YYadr; 


// 


input ( 1 ) 


output (1) 
















wire 


[2: 


0] 




_00_ 


_YYctrl / 


// 


input (1) 


output ( 1 ) 
















wire 


[63 


:0] 


w_ 


_0 0_ 


^YYdata; 


// 


inout (2 ) 


wire 


[1: 


0] 




^oo] 


_ZZack; 


// 


input ( 1 ) 


output ( 1 ) 
















wire 


[15 


:0] 


w_ 


_00_ 


_ZZdata; 


// 


inout (2) 


wire 


[1: 


0] 




^oo] 


_ZZreq; 


// 


input ( 1) 



output (1) 

//////////////////////////////// 



wire 

wire 

wire 

wire 

wire 
output ( 1) 

wire 
output (1) 

wire 
output ( 1) 

wire 
output (1) 

wire 
output ( 1 ) 

wire 
output (1) 

wire 
output ( 1 ) 

wire 



W_ 0 0 _c 1 k_2 xn ; 
W_0 0_c 1 k_2 xp ; 
W_00_clkn; 
W__0 0_clkp; 
[3:0] W 00 inXXack; 



/ / input ( 1 ) output ( 1 ) 
// input (1) output (1) 
// input (1) output (1) 
// input (1) output (1) 
// input (1) 



[63 : 0] W_00_inXXadr_dat ; 
[3:0] W_00_inXXreq; 
[3:0] W_00_outXXack; 
[63 : 0] W__00_outXXadr_dat ; 
[3:0] . W_0 0_outXXreq ; 

W_0 0_powergood ; 



// input (1) 

// input (1) 

// input (1) 
// input (1) 
// input (1) 

// input (1) 



W_00_reset; // input (1) output (1) 

//////////////////////////////// 
///// Module Instancies Section 
//////////////////////////////// 



//// BRIDGE__0_CPU_0_FBUS__XCHG -> IND_CON -> FBUS_xchg 

//////////// 

fbus_xchg BRIDGE_0_CPU_0_FBUS_XCHG ( 

.XXadr_dat (W_0 0_XXadr__dat ) , 

.XXreq (W_0 0__XXreq) , 

.XXack (W_00_XXack) , 

. inXXadr_dat (Wl_00_outXXadr__dat ) , 

. outXXadr_dat ( W1_0 0_inXXadr_dat ) , 

. inXXreq (Wl_0 0_outXXreq) , 

.outXXreq (Wl_00_ihXXreq) , 

.inXXack (Wl 00 outXXack) , 
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.outXXack (Wl_00_inXXack) ) ; 

//// CMEM_0 -> DUT -> CMEMD //////////// 
ctnetn CMEM_0 ( 

5 .YYadr (W_00_YYadr) , 

.YYdata (W_00_YYdata) , 

.YYctrl (W_0 0_YYctrl) , 

.elk (CLK_66MHz) , 

.reset (RESET) , 
10 .power good (POWER_GOOD) ) ; 

//// CIO_0 -> DUT -> CIOD //////////// 

cio CIO_0 ( 

.ZZdata (W_00_ZZdata) , 

15 .ZZreq (W_00_ZZreq) , 

.ZZack (W_00_ZZack) , 

.elk (CLK_66MHz) , 

. reset (RESET) , 
.powergood (P0WER_G0OD) ) ; 



20 

//// BRIDGE_0 -> DUT_CORE -> BRD //////////// 
bridge_core BRIDGEND ( 





. inXXadr_dat 


(W1_0 0_inXXadr_da t ) 




. outXXadr_dat 


{ W1_0 0_outXXadr_dat ! 


25 


. inXXreq 


(Wl_0 0_inXXreq) , 




. outXXreq 


(Wl_0 0_outXXreq) , 




. inXXack 


(Wl_00_inXXack) , 




. outXXack 


(Wl_0 0_outXXack) , 




.YYadr . 


(W__0 0_YYadr) , 


30 


.YYdata 


(W__0 0_YYdata) , 




.YYctrl 


(W_00_YYctrl) , 




. ZZdata 


(W_00_ZZdata) , 




. ZZreq 


(W_00__ZZreq) , 




.ZZack 


{W_00_ZZack) , 


35 


.clk_2xp 


(W_0 0_clk_2xp) , 




. clk_2xn 


(W_00_clk_2xn) , 




. clkp 


{W_00_clkp) , 




. clkn 


(W_00_clkn) , 




. reset 


(W_0 0_reset) , 


40 


. powergood 


(W_00_powergood) ) ; 



//// CPU_0_BRIDGE_0_FBUS_XCHG -> IND_CON -> FBUS_xchg 
//////////// 

fbus_xchg CPU__0_BRIDGE_0_FBUS_XCHG ( 

4 5 .XXadr_dat (W_0 0_XXadr_dat ) , 

.XXreq (W_0 0_XXreq) , 

.XXack (W_00_XXack) , 

.inXXadr dat (W 00 outXXadr_dat) , 
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. outXXadr_dat 
. inXXreq 
. outXXreq 
. inXXack 
. outXXack 



(W_0 0_inXXadr_dat) , 
(W_0 0_outXXreq) , 

(W_^00_inXXreq) , 
(W___00_outXXack) , 

(W 00 inXXack) ) ; 



//// CPU^O -> XACTOR -> FBUS__p //////////// 
f bus_p CPU 0 XACTOR_FBUS_p { 



10 



15 



. inXXadr_dat 

. outXXadr_dat 

. inXXreq 

. outXXreq 

. inXXack 

. outXXack 

.elk 

» reset 

. power good 



{W__0 0_inXXadr_dat) , 
( W_0 0__outXXadr_dat ) 
(W_00__inXXreq) , 

(W_0 0_outXXreq) , 
{W_00_inXXack) , 

(W_00_outXXack) , 
(CLK__66MHz) , 
(RESET) , 

(POWER GOOD) ) ; 



20 



//■// BRIDGE_ 
sys_bridge 



sys -> SYS_CON -> BRIDGE_sys //////////// 
'#(0, 32 'hOOOOOOO?) BRIDGE__0_sys ( 



25 



. clk_2xp 
. clk__2xn 
. clkp 
. clkn 
. reset 
. powergood 
. sys_CLK_2X 
. sys__CLK 
. sys_RESET 



(W_00_clk_2xp) , 

( W__00_clk_2xn) , • 

(W_00_clkp) , 

(W_00_clkn) , 

(W_00_reset) , 

(W_0 0___powergood) , 
(CLK_66MHz) , 

(CLK_3 3MHz) , 

(RESET) , 



30 



. sys_POWER_GOOD 



(POWER GOOD) ).; 



endmodule 



35 



///////////// 

I / END 

/iiii/inn/i 
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ANNEXE 

A7 - Fichiers resultat C++ 

/////////////////////////////////////// 
II FILE GENERATED by A.W. PERL SCRIPT 
5 // FROM patent/sim/conf igs/pat03 .cfg file 
// FOR server 

iiiiiiiiiiiiiiinnifi/iiinmin/iiii 



10 iiiiiiniiiii 

# include " server__registry . hpp" 
#include " server__components . hpp" 



15 I nil mi I III 



const string ServerRegistry : :m_serverName = "SERVER"; - 
const string ServerRegistry: :m_configName = "pat03"; , 
20 const int ServerRegistry: : m^serverNumber = 1; 
Status InstantiateConf igurationO { 
////////////// 

static Fbus__hwif CPU_0__XACTOR_FBUS_p (LabelClass : : CPU^O , 
25 TypeClass : :FBUS_type, 

string { " top . CPU_0_XACTOR__FBUS_p " ) ) 
static Cio_Dut CIO_0 (LabelClass : : CIO__0 , TypeClass : : DUT, 

string ( "top . CIO_0 " ) ) ; 
static Cmem_Dut CMEM__0 (LabelClass : : CMEM_0 , 
30 TypeClass : :DUT, 

string ( " top . CMEM_0 " ) ) ; 
static Bridge_Dut BRIDGE_0 (LabelClass : : BRIDGE_0 , 
TypeClass: :DUT_CORE, 

string ( " top . BRIDGE__0 " ) ) ; 
35 static CPU_Xactor CPU_0_XACTOR (LabelClass : : CPU_0 , 
TypeClass: :XACTOR, 

&CPU_0__XACTOR_FBUS_p) ; 
static CPU_Monitor CPU_0_MONITOR (LabelClass : : CPU_0 , 
TypeClass: : MONITOR, 
4 0 &CPU_0_XACTOR_FBUS_p) ; 

static Fbus_Xchg BRIDGE_0_CPU_0_FBUS_XCHG 
(LabelClass: :BRIDGE_0_CPU_0 , TypeClass: :FBUS_XCHG, 

string ("top. BRIDGE_0_CPU_0_FBUS_XCHG") ) ; 
45 .static Fbus_Xchg CPU_0_BRIDGE_0_FBUS__XCHG 

(LabelClass: : CPU_0_BRIDGE__0 , TypeClass: :FBUS_XCHG, 
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string { " top . CPU_0__BRIDGE_0_FBUS_XCHG" ) ) 
return Success; 

} 

///////////// 

I / END 

///////////// 
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REVENDICATIONS 

1 . Procede d^etablissement automatlque, au moyen d'un systeme de 
traitement de donnees (40) associe a un programme dit Configurateur pour 
5 constituer un modele global de simulation d'une architecture comprenant des 
modeles de circuits integres en developpement pouvant constituer, a I'aide 
du Configurateur automatique, une machine ou une partie d'une machine et 
des modeles d'envlronnement de simulation, permettant de tester et de 
verifier le circuit en developpement, d'un fichler de definition de configuration 

10 (FCONF) de composants de {'architecture, ces composants constituant des 
blocs fonctionneis determines de description des fonctionnalites de circuits 
integres ou de parties de circuits integres, les composants etant choisis par 
Tutilisateur dans une bibliotheque de differents types de composants et une 
bibliotheque de composants d'environnements pour constituer le modele 

15 global de Tarchitecture repondant a la specification fonctionnelle definie dans 
le fichier de definition de configuration (FCONF) et conforme a la 
specification de Tarchitecture du modele global specific par un fichier de 
description de Tarchitecture (FDARCH), precede caracterise par le fait qu'il 
comporte les etapes suivantes: 

2 0 - lecture du fichier de description d'architecture (FDARCH) du 

modele global et memorisation, dans une table de composants et de regies 
de connexion (TCRC), dans une table de regies de coherence de connexions 
(TRCOH) et dans une table de formatage de fichiers source (TMFT), des 
informations relatives a Tensemble des configurations possibles, chaque 

2 5 composant obtenant un nom (LABEL) identifiant, de fagon non equivoque, sa 

position dans Tarchitecture, ainsi qu'un type parmi plusieurs types 
(Composants actifs, Blocs de Monitoring et de Verification, Blocs 
intermediaires, Blocs systemes et Blocs Globaux), 

- instanciafion des composants, specifies dans le fichier de 

3 0 definition de configuration (FCONF) par Tutilisateur-concepteur au moyen 

d'une liste de composants presents designes par leurs nom et type et 
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cbmportant des parametres ou faisant appel a des procedures, le fichier de 
definition de la configuration (FCONF) comprenant un fichier de selection des 
composants et de leur type et des indications supplementaires optionnelles 
concernant le type d'interface et le serveur concerne par la configuration a 
5 generer par le Configurateur, et memorisation des informations 
correspondantes dans une table de connexion des instances (TCINST), 

- connexion topologique des instances et memorisation des 
informations correspondantes dans une table de connexion des instances 
(TCINST), 

10. - connexion physique des signaux d'interface. au niveau de 

chaque instance des composants. par application d*expresslons regulieres, 
memorisees dans la table de composants et de regies de connexion (TCRC) 
portant sur le nom des signaux constituant une table de cablage (TCAB), 

- utilisation de la table de connexion des instances (TCINST), de 
15 la table de cablage (TCAB) et de la table de formatage (TFMT) pour generer 

automatiquement des fichlers source de type HDL (MGHDL) et de type HLL 
(MGHLL) du modfele global de simulation, correspondant a la configuration 
sp6cifiee par le fichier de definition de configuration (FCONF). 

2. Precede selon la revendication 1, dans lequel le syst^me 
2 0 Configurateur transmet aux parties de type HLL de chaque composant 

comprenant des informations sur : 

- le nom (LABEL) du composant, 

- le type de I'instance (DUT. XACTOR, VERIFIER, MONITOR), 

le chemin HDL, a savoir le nom hierarchique du composant dans la 

2 5 description du modele. 

3. Precede selon la revendication 1 ou 2, dans lequel le fichier de 
definition de la configuration (FCONF) comporte en plus un mot-cle 
(serveur<n>) indiquant le nom ou numero du serveur sur lequel se trouve 
instancie un composant dans le cas d'une utilisation du precede sur un 

3 0 systeme multi-serveur. 
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4. Precede selon la revendication 3, dans lequel, dans le cas d'une 
utilisation multiserveur, le systeme configurateur execute les etapes 
suivantes : 

- decoupage de la Configuration en plusieurs parties (de type 
HDL et de type HLL) en triant les composants de type HDL et 
les objets HLL selon leurs appartenances aux serveurs, 

- generation des composants de type HDL peripheriques servant 
a renvoi et la reception des signaux entre les parties de la 
configuration, 

- duplication des Blocs Globaux par le systeme Configurateur et 
instanciation des Blocs Globaux dupliques sur chaque serveur, 

- generation des parties de type HLL servant de support de 
communication entre les serveurs. 

5. Precede selon la revendication 3 ou 4, dans lequel la connexion 
automatique entre les composants par le systeme Configurateur comprend 
plusieurs phases : 4 

- une phase topologique de haut niveau realisant la selection 
des composants et leurs positionnements respectifs, 

- une phase de cablage r6alisant la connexion effective entre 
les composants, cette phase generant comme resultat une 
table de cablage (TCAB) associant les signaux connectes 
ensemble, au nom unique du fil les connectant, 

- une phase de generation des fichiers sources de type HDL et 
de type HLL. 

6. Precede selon la revendication 5, dans lequel la phase de cablage 
est effectuee par le systeme Configurateur selon les trois etapes suivantes : 

a. les Blocs Globaux et les Blocs Systeme sont connectes en 
premier a tous les composants, 
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b. viennent ensuite les connexions des signaux entre les autres 
composants, 

c. a la fin du cablage, une passe supplementaire permet de 
connecter les signaux restant non connectes de chaque composant a 

5 des signaux predetermines pour assurer un etat stable et determine, 

ie systeme Configurateur generant alors des configurations partielles 
comprenant un sous-ensemble de Tarchitecture. 

7. Precede selon la revendlcation 6, dans lequel les signaux 
predetermines sent les signaux du Bloc Systeme correspondant au 

10 composant 

8. Precede selon une des revendications 1 a 7, dans lequel Ie fichier 
de description de Tarchitecture (FDARCH) du modele global comprend les 
modeles de simulation des Blocs globaux et des Blocs Systeme, ces deux 
types de composants etant connectes entre eux et gerant des signaux 

1 5 d'environnement. 

9. Precede selon la revendication 8, dans lequel les Blocs Systeme 
sent connectes aux autres composants et leur fournissent des signaux 
systeme qui leur sent specifiques. 

10. Proc§d6 selon la revendication 9, dans lequel Ie systeme de 
2 0 traitement de donnees (40) effectue un contr6le de conformite des 

connexions en comparant la table de connexion des instances (TCINST) 
reelles entre blocs avec la table de regies de coherence de connexions 
(TRCOH). 

11. Precede selon la revendication 10, dans lequel Ie systeme de 
2 5 traitement de donnees (40) compare les connexions physiques entre les 

composants a la table de regies de coherence de connexions (TRCOH), pour 
detector des incompatibilites entre extremites de connexions entre les 
composants, et, en . pareil cas, il specifie, et ajoute, dans la table de 



4 
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connexion des instances (TCINST), un composant adaptateur (Bloc 
Intermediaire) (101) insure dans la connexion consideree. 

12. Procede selon la revendication 11, dans lequel le fichier de 
definition de configuration (FCONF) comprend des informations, specifiees 

5 par un attribut, concernant Tutilisation de composants adaptateurs (Blocs 
intermediaires) avec les Instances des Composants actifs, dont les 
connexions sont comparees a la table de connexion des instances (TCINST), 
pour detecter des incompatibilites entre extremit§s de connexions entre les 
composants. et, en parell cas, 11 specifle, et ajoute, dans la table de 
10 connexion des instances (TCINST), un autre composant adaptateur (Bloc 
intermediaire) (102) Insere dans la connexion consideree. 

13. Procede selon la revendication 12, dans lequel le system^ de 
traitement de donnees (40) s6lectionne certaines des connexions e.ntre 
composants de la table de regies de coherence de connexions (TRCOH) et 

15 specifie, et ajoute, dans la table de connexion des instances (TCINST),;des 
connexions supplementaires constituent des derivations aboutissant ^ des 
modeles supplementaires respectifs, representant des outils de surveillance 
(sondes) des connexions. 

14. Procede selon Tune des revendications 1 a 13, dans lequel, 
2 0 dans la phase de generation des fichiers sources, le systeme Configurateur 

genere les fichiers source en langage HDL (MGHDL) et en langage HLL 
(MGHLL) en s'appuyant sur le contenu de la table de composants et de 
regies de connexion (TCRC), la table de regies de coherence de connexions 
(TRCOH), la table de formatage des fichiers source (TMFT), la table de 
25 connexion des instances (TCINST) et la table de cablage (TCAB). 

15. Procede selon la revendication 14, dans lequel le systeme de 
traitement de donnees (40) effectue un traitement par le systeme 
Configurateur, pour chaque variante de configuration, pour obtenir plusieurs 
modeles de simulation correspondent a la meme specification fonctionnelle. 
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mais ecrits en une description comportant differents melanges des langages 
de niveaux differents (HDL, HLL). 

16. Procede selon I'une des revendications 1 a 15, dans lequel le 
systeme de traitement de donnees (40) etablit la specification fonctionnelle 
du modele global de simulations dans un format informatique compatible 
avec un langage de programmation de haut niveau (HLL) et en format 
compatible avec un langage de description du materiel (HDL). 

17. Procede selon une des revendications 15 ou 16, dans lequel le 
fichier de definition de configuration (FCONF) comprend, pour chaque 
composant, au moins une partie en langage de type HDL, ladite partie en 
langage de type HDL fournissant une interface vers d'autres modeles. 

18. Procede selon la revendication 17, dans lequel les modeles 
comprenant une partie en langage de type HLL comprennent des 
adaptateurs d'interface. 

19. Procede selon la revendication 18, dans lequel le systeme 
Configurateur choisit chaque modele d'adaptateurs d'interface en fonction de 
la table de regies de coherence de connexions (TRCOH). . _ . 

20. Procede selon la revendication 19, dans lequel les connexions 
des signaux physiques sont specifies par des "Ports", chaque port etant une 
selection arbitraire des signaux de ['interface de type HDL d'un composant a 
Taide des expressions regulieres portant sur les noms de ces signaux, et 
etant constitue de paires expression reguliere / expression de substitution, 
ces expression etant appliquees successivement au nom de chaque signal 
de I'interface de type HDL, et, si la substitution finale est identique pour deux 
signaux, ces derhiers sont connectes entre eux, la connexion etant 
memorisee dans la table de cablage (TCAB). 
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21. Procede selon la revendication 20, dans lequel chaque adaptateur 
d'interface etant partage entre plusieurs modeles connectes sur le meme 
port, un seul de ces modeles emet des signaux sur ledit port. 

22. Systeme de traitement de donnees (40) pour retablissement 
5 automatique d'un modele global de simulation d'une configuration de blocs 

fonctionnels determines, mutuellement relies par des connexions 
d'interfonctionnement, pour constituer le modele global de simulation d*une 
architecture comprenant des modeles de circuit integres en developpement 
pouvant constituer une machine r^pondant a la specification fonctionnelle 

10 d'une configuration, systeme caracterise par le fait que le systeme de 
traitement de donnees (40) utilise un programme Configurateur 
(PROGCONF) qui comprend des moyens de realiser une simulation- du 
cablage par Tapplication d'expressions r6gulieres memorisees, d'utiliser un 
fichier de definition de configuration (FCONF) en langage de haut niveau, 

15 une table de composants et de regies de connexion (TCRC) decrivant les 
proprietes (type. Interfaces de type HDL, ports, constructeurs d'objets de 
classes HLL, etc..) des composants logiciels de simulation du circuit,, une 
table de regies de coherence de connexions (TRCOH) en langage de^:haut 
niveau (HLL), des moyens d'instancier les elements resultants du fichier de 

2 0 definition de configuration (FCONF). un gen6rateur du code HLL qui combine 
les parametres des composants avec les regies de connexion. 

23. Systeme selon la revendication 22, caracterise en ce qu'il existe 
au moins cinq types de composants : les Composants actifs, les Blocs de 
Monitoring et Verification, les Blocs intermediaires. les Blocs Systeme et les 

2 5 Blocs Globaux. 

24. Systeme selon la revendication 23, caracterise en ce que le 
systeme est agence pour effectuer un controle de conformite des connexions 
en comparant la table de connexion des instances (TCINST) avec une table 
de regies de coherence des connexions (TRCOH) physiques entre les 

3 0 modeles choisis des blocs constituant le modele global. 
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25. Systeme selon la revendication 24, caracterise en ce qu'il est 
agence pour comparer la table de connexion des instances (TCINST) reelles 
entre blocs a la table de coherence des connexions (TRCOH), pour detector 
des incompatibilites entre extremites de connexions entre blocs, et, en pareil 

5 cas. pour specifier, et ajouter, dans la table de regies de coherence des 
connexions (TRCOH), un bloc fonctionnel adaptateur (Bloc Intermediaire) 
(101) insere dans la connexion consideree. 

26. Systeme selon une des revendications 22 a 25, caracterise en ce 
que la table de composants et de regies de connexion (TCRC). comprenant 

10 les proprietes des composants, contient des parametres globaux communs a 
tous les types de composants et se presente sous forme d'une table repartie 
suivant une ou plusieurs tables, associatives ou non, dont les entrees sont 
des noms designant Tensemble des modeles possibles pour un meme 
composant. 

15 27. Systeme selon la revendication 26, caracterise en ce que les 

tables associatives peuvent contenir la description, soit sous forme de suites 
de parametres, ou bien sous forme de references a des procedures qui 
generent les valeurs requises, les entrees de ces tables associatives etant 
des noms designant Tensemble des modeles possibles pour un meme 

2 0 composant et formant une chame de caracteres contenant des identificateurs 
speciaux predetermines, substitues par les valeurs calculees par le systeme 
Configurateur. 

28. Systeme selon la revendication 27, caracterise en ce qu'au moins 
trois selecteurs indiquent ['instance a prendre en compte, cette derniere etant 
2 5 transmise comme parametre a un constructeur d'un objet HLL : 

- un premier selecteur indique Tinstance ("item") courante, 

- un deuxieme selecteur precise Tinstance connectee a Tautre 
extremite du port, 
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- un troisieme selecteur indique I'instance compos^e 
correspondant au Composant actif contenant le port 
d'observation. 

29. Systeme selon Tune des revendications 22 a 28, caracterise en ce 
que le systeme Configurateur utilise une ou plusieurs tables de regies de 
coherence de connexions (TRCOH), qui representent ies regies 
d'interconnexion entre Ies composants et d'insertion des composants 
intermediaires, une ou plusieurs tables de connposants et de regies de 
connexions (TCRC). qui representent Ies regies de connexion niveau 
systeme et Ies regies de generation de connexions entre Ies signaux, et une 
ou plusieurs tables de formatage de fichiers source (TFMT), qui representent*. 
Ies regies de generation des instances des objets de type HLL. 

30. Systeme selon Tune des revendications 22 a 29, caracterise en ce 
que le systeme Configurateur utilise : 

- une classe de base en HLL permettant d'identifier de fagon uniyoque 
chaque objet instancie et d'interroger la configuration, * 

- des moyens de generation et dMnstanciation automatique des Blocs 
Systeme, 

- des moyens des tableaux associant Ies signaux connectes ensemble 
au nom unique du filles connectant, 

- des moyens d'utiliser un tableau de formatage pour generer Ies 
fichiers sources en HDL et HLL. 

31. Systeme selon Tune des revendications 22 a 30, caracterise en ce 
que Toperateur specifie fonctionnellement, dans la plus large mesure 
possible, la configuration dans le langage de plus haut niveau et il complete 
la specification fonctionnelle par Ies composants en langage de plus bas 
niveau. 

32. Systeme selon une des revendications 22 a 31, caracterise en ce 
que Ies entrees suivantes du hachage definissent le Type du composant (par 
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exemple DUT (modele HDL). XACTOR (transactor). MONITOR. VERIFIER 
* ou autres) et, a chaque Type de Composant, correspond un hachage 
compose a son tour des entrees suivantes : 

- une prenniere entree ReqModufe - contient le nom du module HDL 
5 du composant et le nom du fichier source correspondant, 

- une deuxieme entree Connect - est la definition de la methode de 
selection des signaux faisant partie d'un Port, cette description 
etant compos6e d'une suite d'entrees indexees par le nom du 
Port ; a chaque nom de Port, le configurateur associe un tableau 

10 d'expressions r6gulieres et un pointeur sur une procedure de 

connexion des signaux qui gere Tapplication de ces expressions 
aux noms des signaux de interface du composant 

33. Systeme selon la revendicatlon 32, caracterise en ce que la 
structure generique des Composants actifs comprend un Bloc contenant la 

15 description HDL et un Bloc en HLL, fournissant les chemins d'acces aux 
ressources HDL et, le cas echeant. une description du bloc en HLL, 
Tensemble des signaux du bloc HDL constituant I'interface du Bloc 
englobant, formee, d'une part, de Ports, qui sont des selections logiques 
arbitraires des signaux d'une interface et, d'autre part, d'adaptateurs 

2 0 d'interface qui sont les parties logicielles assurant, sur chaque Port, la 
communication bi-directionnelle entre les parties en HLL et celles en HDL, 
les adaptateurs d'interface etant choisis par le systeme Configurateur. 

34. Systeme selon la revendicatlon 33, caracterise en ce que les Ports 
sont specifies sous forme d'expressions regulieres, qui servent a la fois a 

2 5 selectionner les sous-ensembles de signaux a connecter et a definir les 
regies de connexions. 

35. Systeme selon une des revendications 22 a 34, caracterise en ce 
que le systeme Configurateur genere des Composants dits de Transfert qui 
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sont inseres de chaque cote de la coupure sur les serveurs. ces composants 
etant simplement des fils pour les entrees et des registres pour les sorties. 
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